GitHub Tutorial

A simple guide to GitHub for my fellow students.

What is Git and GitHub?

Git is a distributed version control system that allows developers to track changes in their codebase, collaborate with others, and manage different versions of their software projects. It enables you to work on a project simultaneously with other developers without overwriting each other's work.

GitHub, on the other hand, is a web-based platform that provides hosting for Git repositories. It adds a layer of collaboration tools on top of Git, making it easier to work on open-source and private projects, collaborate with others, and manage your codebase.

Basic Git terminology

Here are some fundamental Git terms that will help you understand and use Git more effectively in your software development projects:

1. Repository (Repo): A repository is a directory or storage space where your project's files and version history are stored. It can be local (on your computer) or remote (hosted on a service like GitHub).
2. Clone: Cloning is the process of creating a copy of a remote Git repository on your local machine. This allows you to work on the project locally and make changes.
3. Pull: Pulling is used to update your local copy of a repository with any changes made to the remote repository. It fetches the changes and merges them into your current branch.
4. Push: Pushing is the opposite of pulling. It's used to upload your local changes to the remote repository. This makes your changes available to others working on the same project.
5. Branch: A branch is a separate line of development within a Git repository. It allows you to work on a feature or bug fix without affecting the main codebase. Branches can be created, switched between, and merged.
6. Commit: A commit is a snapshot of the changes made to a repository at a specific point in time. Each commit has a unique identifier and includes a message describing the changes.
7. Merge: Merging is the process of combining the changes from one branch into another. This is typically done to integrate a feature branch with the main branch (e.g., merging a feature into the "master" branch).
8. Pull Request (PR): A pull request is a way to propose changes to a Git repository hosted on platforms like GitHub. It allows you to submit your changes for review and merge them into the main branch.
9. Fork: Forking is the act of creating a personal copy of someone else's repository on a Git hosting platform. It allows you to make changes to the forked repository independently.
10. Remote: A remote is a version of the repository stored on a server or hosting service like GitHub. It's used for collaboration and sharing changes with others.
11. Origin: In Git, "origin" is a default name for the remote repository from which you cloned your local copy. It's commonly used as the alias for the primary remote repository.
12. Conflict: A conflict occurs when Git cannot automatically merge changes from different branches or commits. You must resolve these conflicts manually.

GitHub Desktop

GitHub Desktop is a user-friendly graphical interface for Git.

1. Install GitHub Desktop: If you haven't already, download and install GitHub Desktop from the GitHub Desktop website.
2. Launch GitHub Desktop: Open the GitHub Desktop application on your computer.
3. Sign in to GitHub: If you have a GitHub account, sign in. If not, you can use GitHub Desktop without signing in, but signing in enables additional features you will need later. So, visit GitHub's website to sign up.

Cloning a repository

To clone a repository using GitHub Desktop, follow these steps:

1. Click on the "File" menu and select "Clone repository...".
2. In the "Clone a Repository" dialog, select the "URL" tab.
3. Enter the URL of the GitHub repository you want to clone. You can find the URL on the GitHub repository's page by clicking the green "Code" button.
4. Choose a local path where you want to clone the repository to.
5. Click the "Clone" button.
6. GitHub Desktop will download the repository to your local machine. Once the cloning process is complete, you'll see the repository in your GitHub Desktop application. You are presented with a window to open the repository in your external editor or file explorer.

Note that GitHub Desktop is just a bridge between your local files and GitHub. You edit the codebase locally on your computer, and GitHub Desktop automatically tracks all changes.

Making changes and committing

In the world of Git, there are two main approaches to proposing changes to a project: 'Making a Pull Request' and 'Pushing Directly to Master'. A pull request is a common method preferred in public projects where multiple collaborators are working in parallel. It enables developers to propose their changes in a separate branch, maintaining isolation from the master branch until changes are reviewed and approved. This practice ensures maintainability and avoids potential conflicts amongst concurrent changes.

However, in smaller projects like our student projects, it's common to have a single branch only, i.e., the master branch. This is the case for all the student projects hosted on my GitHub account. In such scenarios, you push your changes directly to the master branch. While this approach might be less complex, caution should be taken to ensure changes are carefully reviewed before pushing, as they affect the project immediately.

Making a Pull Request

Pull requests (PRs) are a way to propose changes to a repository hosted on GitHub. They allow you to suggest modifications, improvements, or fixes to the project. GitHub Desktop makes it easy to create and manage pull requests for your Git repositories. Here are the steps to make a pull request using GitHub Desktop:

1. Open GitHub Desktop: Launch the GitHub Desktop application on your computer if it's not already open.
2. Select the Correct Repository: Make sure you're working with the repository where you want to create a pull request. You should see your repository listed in the left sidebar of the application.
3. Create a New Branch: Before making changes and creating a pull request, it's best practice to create a new branch for your feature or bug fix. This keeps your changes isolated from the main branch. To create a new branch:
   • Click the "Current Branch" dropdown in the top-left corner of the GitHub Desktop window.
   • Click "New Branch."
   • Give your branch a descriptive name (e.g., "my-feature-branch").
   • Click the "Create Branch" button.
4. Make and Commit Changes: Make the necessary changes to your code in the newly created branch. Once you've made your changes, you need to commit them:
   • In GitHub Desktop, you'll see the changes you've made in the "Changes" tab.
   • Enter a summary and, if necessary, a more detailed description of your changes in the commit message box.
   • Click the "Commit to my-feature-branch" button.
5. Push the Branch to GitHub: After committing your changes, you need to push your branch to your remote repository on GitHub:
   • Click the "Publish branch" button in the top-right corner of the GitHub Desktop window. This pushes your branch to GitHub.
6. Create the Pull Request:
   • After pushing your branch, you'll see a notification in GitHub Desktop that you can create a pull request.
   • Click the "Create Pull Request" button in the notification.
7. Review and Confirm:
   • GitHub will open in your web browser, showing the details of your pull request.
   • Add a title and description to your pull request, explaining what changes you made and why they are necessary.
   • Review the changes made in your pull request.
   • Once you're satisfied with everything, click the "Create pull request" button.
8. Wait for Review: The repository owner or maintainers will review your pull request. They may leave comments or request further changes.
9. Merge the Pull Request: If the reviewers are satisfied with your changes, they can merge your pull request into the main branch.

Pushing to Master

Pushing commits to the master branch is one of the core functionalities of Git. You can propose changes to the project, which are stored in form of commits, and push them to the master branch when you have necessary rights. Here are the steps to commit and push to the master branch using GitHub Desktop:

1. Open GitHub Desktop: Start the GitHub Desktop application on your machine if it's not running.
2. Select the Right Repository: Check that you're working with the correct repository where you want to commit and push your changes. You will find your repository listed in the left sidebar of the application.
3. Ensure You're on the Master Branch: Unlike making a pull request, for committing and pushing changes directly to the master branch it's not necessary to create a new branch. Confirm that you're indeed on the 'Master' branch:
   • Click the "Current Branch" dropdown in the top-left corner of the GitHub Desktop window.
   • Select "master" from the dropdown list.
4. Implement and Commit Changes: Proceed to make necessary changes to your code. After modifying the code, it's time to commit them:
   • In GitHub Desktop, navigate to the "Changes" tab where you'll see the changes implemented.
   • Provide a brief summary and if required, an elaborate description of the changes you've made in the commit message box.
   • Click the "Commit to master" button.
5. Push the Changes to GitHub: The next step after committing your changes is to push them to your remote repository on GitHub:
   • Click the "Push origin" button located in the top-right corner of the GitHub Desktop window. This action pushes your modifications to the master branch on GitHub.
6. Review the Changes:
   • GitHub will automatically synchronize and show the new commits to the master branch.
   • Confirm your changes by navigating to your online GitHub repository and check under the "Commits" section.
7. All Set: The committed changes are now a part of the master branch, and are visible to all team members. As such, they can be pulled into local copies of the repository for further work.

Note: Directly pushing to master might result in conflicting changes if done without coordination in a team with multiple contributors. Thus it is recommended to use carefully within small teams or individual projects.