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.

Configuring your identity #

git records who authored each commit. Tell it your name and the email address associated with your GitHub account:

% git config --global user.name "Your Name"
% git config --global user.email "you@example.com"

If you skip this step, git doesn’t refuse to commit. Rather, it silently guesses a name and email from your computer’s account settings and hostname, which won’t match your GitHub account, and your commits will carry the wrong identity, so it’s best to set it explicitly now.

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:

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.

Creating and cloning your repository #

Problem set and lab repositories are generated on demand by generate.cs51.io.

Make sure you’ve submitted the CS51 start-of-term survey with your GitHub username first. generate.cs51.io depends on having your GitHub username on file from that survey, so the survey needs to be submitted before it can generate a repository for you. (You only need to do this once, not once per assignment.) If you visit your assignment link and see a message saying it can’t find your enrollment or your GitHub username, make sure you’ve completed the survey, then try the link again.
Go to https://generate.cs51.io/?assignment={assignment}, where {assignment} is the problem set or lab identifier (e.g. ps1 or lab3). Course staff will give you the exact link for each assignment.
Sign in with HarvardKey if prompted.
generate.cs51.io creates your repository (if it doesn’t already exist) and lands you on a “Your repository is ready” page. Click “Open your repository” to go to it on GitHub. (If GitHub shows a “Not Found” page for a moment, just refresh the page – it can take a few seconds for access to propagate.)
Click the “Code” button.
Select “SSH” if needed.
Copy the SSH URL for the generated repo, of the form git@github.com:<org>/{assignment}-{your-github-username}.git.
We recommend that you place all your local problem set and lab repositories in a directory for that purpose, say psets for problem sets and labs for labs. Create the directory, if you haven’t already, and change to it:
```
% mkdir psets
% cd psets
```

Clone the repository into a subdirectory named after the assignment:

% git clone {SSH URL from your clipboard} {assignment}

If all went well, you should have seen something like this:

Cloning into '{assignment}'...
remote: Counting objects: 51, done.
remote: Compressing objects: 100% (51/51), done.
remote: Total 51 (delta 51), reused 51 (delta 51)
Receiving objects: 100% (51/51), 51 MiB | 51 MiB/s, done.
Resolving deltas: 100% (51/51), done.

Now go to the directory for your just-created local repository:
% cd {assignment}

Working with a partner #

Some psets (see the assignment’s own instructions for which ones) allow two students to submit one shared solution. Setting this up is self-service through generate.cs51.io, with no separate sign-up form:

Visit https://generate.cs51.io/?assignment={assignment} and sign in, same as above. On a partner-eligible assignment, instead of landing straight on “Your repository is ready”, you’ll see a choice between working solo and inviting a partner.
To invite a partner, enter their GitHub username (the one they used on the CS51 start-of-term survey – they must have already submitted it, same as you). You’ll land on a “waiting for your partner” page; nothing else to do until they respond. There’s no other notification sent, so tell your partner directly that they need to visit the same assignment link themselves, signed in as themselves.
When your partner visits that link, they’ll see your invite with an Accept/Decline choice. Accepting creates one shared repository – named from both of your GitHub usernames, e.g. {assignment}-{username1}_{username2} – and adds you both as collaborators. From there, cloning it is the same as above: whoever visits the link next (either of you) lands on the normal “Your repository is ready” page for the shared repo.
Only one of you needs to submit the shared repository to Gradescope – either partner can be the one to do it. After submitting, use Gradescope’s “Add Group Member” option on that submission to add the other partner, so the one submission counts for both of you. Don’t have both partners submit separately; that just creates two disconnected submissions instead of one shared one, and is likely to trigger Gradescope’s plagiarism detector.
If you need to stop working with your partner (e.g. to work solo, or with someone else instead), either of you can click “Leave this partnership” on the ready page. This archives the shared repository (read-only) for both of you, and returns you to the solo-or-invite choice – there’s no way to keep working in the old shared repo from one side while the other starts fresh, since it becomes read-only for both at once. Your partner will see the same “start fresh” choice next time they visit the assignment link.