In this article, we’ll summarize some basic operations using the git version control system using the GitHub platform.

Using Git

For a more detailed introduction to git, see this book.

Creating an SSH Key

SSH Keys allow you to present a certificate to the GitHub server that authenticates your user account from your computer. It is an alternative to password-based authentication. You can create an SSH key, which will create two files on your “home directory” called .ssh/id_rsa and .ssh/id_rsa.pub. The .ssh/id_rsa.pub file contains your public key and is the file you will share with GitHub. The private key in the other file corresponds to your public key, and, as the name implies, should not be shared with anyone (as it will enable authentication against the public key).

Once the key is created, you can copy the public key text and paste it on the GitHub website to add it. It’s a good idea to name the key, in case you get a new computer and start a new key; it’s a good practice to remove unused public keys from GitHub and other servers.

If you are using TortoiseGit, you can use a tool to manage your SSH keys from Windows. See this article for details.

Creating a Repository

Using the Repository

Clone

Cloning the repository downloads it to your local computer. You can do this as many times as you wish, and synchronize across them. You can even share the repository with other users, and they can operate on the repository locally as well.

Basic Repository Operations: Add, Commit, and Push

Sometimes, you’ll have private files in your repository directory that are important, but too senstive (or just custom to each local computer) to save to the remote repository in the cloud. For this reason, you’ll explicitly add each file that you want to upload to the cloud. Note that you also add files that you’ve modified even if they already exist.

Once you’ve added your file(s), you can commit your changes to the repository. This creates a log timestamp that you can see in the repository to track who did what and when. You can even roll back your repository to any point in time marked by one of these commits. It’s a good idea to commit relatively often, whenever a major milestone is reached that you might like to revert to or review someday. It’s also a good idea to specify a commit log message so that these commits make sense beyond simply what files were modified and how. This is specified with the -m flag to git commit.

Before git came along, repositories would often automatically sync to the remote in the cloud as soon as a commit was made. This might even seem reasonable at first glance. But not all computers are connected to the Internet at all times, and so it is helpful to separate these operations so that you can make commits while offline. After you have made one or more commits, you can push them to the remote in the cloud.

Other Operations: Removing files, Pulling

In addition to adding files, you can also remove files from the repository with git rm. You’ll commit and push these changes just like with add operations.

One final note: it’s a good practice to pull the repository from the remote cloud before performing a push operation. In fact, it’s required if anyone else has pushed commits that you have not yet downloaded. You can use the git pull command to do this, and should plan on doing this at least any time you push.

Branching

Things can get messy if there are many people working on many different parts of a repository with different objectives in mind. It is nice to have a “sandbox” to work in that is separate from the rest of the team, and then to merge that sandbox back into the master repository when you are finished. These “sandboxes” are called branches. You can create a branch using the git branch <branch name> command, and switch between branches using the git checkout <branch name> command. Git provides a shortcut when creating a new branch that executes both operations: git checkout -b <branch name>.

Initially, the branch will be identical to the current branch, but it will be on its own independent commit timeline.

You can commit and push to your branch like before. When pushing to (or pulling from) a particular branch, you can specify the branch to git via git push <remote> <branch name>. By default, the GitHub remote is called origin, so you would enter git push origin <branch name>. You can have more than one remote, which would allow you to sync with multiple remote servers or to create custom actions to occur when you push commits. This is beyond the scope of this article as we won’t need it for GitHub classroom, but if you’re interested, you can find out more here.

With GitHub, it’s possible that a single user or subset of users are in charge of the master branch, into which these branches would often be merged. To request a code review and merge of a branch, you can create a Pull Request that seeks a review, comments, and ultimately a merge of the branch.

With GitHub classroom, branches and Pull Requests are useful because they allow students to communicate with instructors about their repository. Students can seek assistance on their code by creating a Pull Request on a branch, and instructors can use the review feature to comment on the student’s attempt down to the line level. However, this is also a good practice for using git and GitHub, and GitHub classroom provides a convenient opportunity to practice these operations in ways that will help the student get assistance on their coursework. More on this later.

Merging a Branch

You can merge a branch into your existing branch using the git merge <branch name> operation. You can checkout the target branch first, and then merge the other branch in.

Notice that you do not need to commit after performing a merge: the merge is a commit on your current branch. If you perform a git commit, it will provide you a helpful reminder about this. Instead, you can go ahead and push to the remote GitHub server when you are ready.

Sometimes, team members make changes to the same parts of the same files in different branches (or from different local checkouts). A conflict occurs when this happens. Git offers you some guidance in how to resolve these, and allows you to specify the details as a new commit. You can find more details on how to do this here.