Setting up git

Setting up git #

Signing up for GitHub #

The git repositories we will work with will be remotely hosted on GitHub, a git service offering remote repositories hosted in the cloud. If you don’t already have a GitHub account, follow these instructions to create one.

Adding an SSH key #

Use SSH to let GitHub identify you and your computer. This lets you avoid having to type in your GitHub password every time you push to save your code remotely (which you should do often). To set up SSH authentication, follow these articles from GitHub:

  1. Checking for existing keys

  2. Generating a new key (if necessary)

  3. Telling GitHub about your key.

Your git should now be fully configured.

Using git #

When you modify some code, reach a good checkpoint in your coding (for example, “fixed bug in function foo”), or finish your work, you can and should commit these changes by executing a git commit command with an appropriate message:

% git commit -am "fixed bug in function foo"

at the terminal from the directory in which you’re working.

You should commit early and often, and push whenever you finish something important, so that your work is backed up on GitHub in the event of a computing emergency (like a spilled cup of coffee).

The -a flag (“a” stands for “all”) here specifies that git should take note of all changes made in files that you have previously told git to track.

  • You can tell git to track a file named filename by adding it, as in:

    % git add filename

  • Since ps0.ml was already added, you don’t have to add it again. However, if you were to make further changes to the file, you would have to add it again to commit the further changes.

  • You can add all of the files in your current directory (and subdirectories) to your repository by running

    % git add --all

    This is probably the safest thing to do (to ensure you’re tracking everything), but you’ll probably not want to track the compiled binaries (like the _build directory and ps0.byte that you’ll shortly be generating).

The -m flag (“m” for “message”), followed by some string, specifies a commit message, which is a short string describing the changes that have been made since the last commit. This can be useful in keeping track of exactly what changes you make throughout the development process. If you work on projects with other people, they can see what other changes you’ve made by reading these commit messages, which they (and you) can see by running git log.

Merely committing will store these changes in your computer’s local copy of the repository. To push this repository’s changes online to GitHub, execute a

% git push

This will create a remote backup of your work so that, in the event of your losing access to your computer, you’ll still have something to work with and submit. This will also set things up to submit your work to Gradescope (though it doesn’t perform the submission process itself; more on this later). Again, commit and push early and often.

If you want a succinct reference for your git usage, see Eddie Kohler’s great guide to Git, as well as the aforementioned video about git for CS 51 by Brian Yu.

Accessing the distribution code #

We provide a link to the git repository for each problem set and lab. These links follow the patterns:

  • http://url.cs51.io/ps{n}
  • http://url.cs51.io/lab{n}

where {n} is the problem set or lab number.

To download all of the materials for a problem set or lab, all you need to do is follow this link to the repository, and on the right of the page above the problem set files, you should see a ‘Code’ option. Click on this option and copy the ‘https’ link to your clipboard. Open your terminal and navigate to the folder where you want your problem set to be saved. Once there, execute:

% git clone {URL from your clipboard} X

This will download the starter code for Problem Set X in a folder named “X”.

Working with a partner #

On partner problem sets, one member of your pair should follow the link on the problem set specification. After clicking this link there is a “Create team” option. Once you enter a name for your team and submit it, your partner can follow the link on the problem set specification and choose that team.

If you want to work solo on a partner problem set, create a team for yourself.

Getting the source code #

We hand out problem set distribution code using GitHub Classroom. Every problem set specification will contain a link to the distribution code. When you click the link, GitHub will create a repository for you to use, and, if applicable, for you to share with your problem set partner.