If you don't have an X display when you log in, you will need to "unset SSH_ASKPASS" (if you use bash) or "unsetenv SSH_ASKPASS" (if you use csh). This will allow git to prompt you for your bitbucket password for any git operations that have to talk to bitbucket (clone, pull, push). On other systems this should not be necessary.

Initial checkout

First, you must check out your directories from the repository before you start. This will give you your own working copy of the files and directory structure. On the GL systems, you'd use a command like this

git clone your_repository directory_name_of_your_choice

The repository link is at the top-right of the bitbucket screen. The choices are SSH or HTTPS. SSH can allow you to do bitbucket server operations without retyping your password, but does not currently work on GL. On GL, you must use the HTTPS one. Just cut and paste it from the bitbucket screen. For example, if you were in data oriented programming and your username was xyzzy, your command might look like this:

git clone dopwork

This will create a directory called "dopwork" containing a new working copy of your files. This is the only time you need to tell it where the repository is. After the initial checkout, once you cd into your working directory, Git can figure out which repository to use. All of the major Git commands apply to the current directory and all directories under it.


Edit away... No need to do anything special

Adding, removing, and ignoring files

Ask Git about the files it doesn't know about yet

git status

You may see sections for files "Changed but not updated" (including files previously checked in that have been modified or deleted), and/or for "Untracked files". If there are any files listed that should not be checked in, edit the .gitignore file and add them to the list of files Git should not track. This includes any files generated when you build — if you didn't create it, you probably don't want to check it in. Once git status just lists the files that should be checked in, you have tell git that you really do mean to remove any that are marked to be deleted:

git rm file

Now tell git what other files you want to commit (for new or changed files)

git add file

This is called "staging" your commit. Now you can commit a local copy of your work. This is not yet submitted, but you can use these intermediate revisions to track your work and go back to prior versions. You should give a short but useful message that will identify the main content of this commit. For example, "Initial parsing code", or "Fixed cross-product bug", etc.

git commit -m "short message"

Getting updates and previous revisions

If I make any changes to the initial sample files (or add some for the later assignments), you can get these using

git pull

You can compare your current file with any previous version

git diff commit_ID

To figure out which commit IDs for comparison is which (assuming you entered reasonable log messages when you committed your changes), do

git log file

You can also select commits by date using a format like '@{1/1/05 13:15 EST}' for the commit ID

Submitting your changes

Your changes are not copied to the repository until you both commit them, and push them to the repository. You must do this for us to be able to check out and grade your work, but you can do it as many times as you want before then. Pushing your changes to the class repository before the deadline can help serve as a backup copy of your work, or allow you to work in multiple locations by copying changes to the main repository whenever you are done at one location before you move to the other. To push to the main repository, just do this:

git pull
git push

Learning more

List of all Git commands


Help on any one Git command

git --help command

And, of course, there are tons of resources on git online