Git is a version control system (VCS) that allows you to keep track of changes to your code and label certain versions as “v1.0” or “v2.0”, etc. In this class, you will use git to submit your homework and project code. Git is widely used in industry, so it’s a good idea to learn it early and use it often.

BitBucket setup

You are required to keep a copy of your homework on the free service BitBucket, as a backup, and as a way for me to look at your code. Sign up for an account there, and tell me your username (as we discussed in class).

Create a new repository for each homework assignment. Keep it private, but add me as a viewer. This will be demonstrated in class.

Git installation


If you use Ubuntu or some other Debian variant, this should work:

sudo apt-get install git

For other distributions, refer to Google, or ask me.


Download msysGit. Use the default options. Run the “Git Bash” program that’s installed in order to use git commands.

Mac OS X

You can install git by installing “Xcode command line tools” with the following command in a terminal:

xcode-select --install

Or, download directly from the git project.

Post-installation configuration

You’ll need to tell git your name and email. Every commit is recorded with a name and email. You should use the same email address you used when you created a BitBucket account.

Execute these commands (use your own name and email!):

git config --global user.name "Joshua Eckroth"
git config --global user.email "jeckroth@stetson.edu"

Basic concepts

Basic workflow

Comments are shown after the # on each line. These commands should work on Linux/Mac OS X/Windows, assuming you have installed Git.

mkdir HW01                            # create a new directory
cd HW01                               # go into that directory
git init                              # create a new empty git repository

(...create BitBucket repository, and add me as a reader...)

# next, register the BitBucket repository;
# of course, CHANGE THIS EXAMPLE to your repository location!
git remote add origin git@bitbucket.org:joshuaeckroth/csci221-HW01.git

(...write some code...)

git add myfile1.txt myfile2.txt       # indicate which files to save in the commit
git commit -m "My first commit!"      # do the commit

(...write some code...)

git commit -a -m "My second commit!"  # record all changed files in the second commit
git push --all                        # upload all commits to BitBucket


As stated above, git allows you to keep track of different commit histories on different “branches.” It’s a good idea, in larger projects, to create a branch for every crazy idea so that you are not mucking with the “master” branch, which usually is the branch delivered to users. Eventually, if your crazy idea works out, you would merge the branch back into master.

git branches

(Image from: GitGuys)

In this example, there are two branches: master and test. The master branch is the usual name for the main production branch. When working in teams, eventually everybody’s changes get collected into the master branch. HEAD always points to the active branch on your personal machine; no matter which branch you’re on, HEAD points to it. We see from the diagram that T1 is a commit that is based off of C2. C3 is a different commit also based off C2. And C2 is based off of C1. The following commands would have produced this scenario:

(...make some changes...)
git checkout master
git commit -a -m "This is commit C1."
(...make some changes...)
git commit -a -m "This is commit C2."
(...make some changes...)
git commit -a -m "This is commit C3."
git checkout <commit id for commit C2>
git branch test
(...make some changes...)
git commit -a -m "This is commit T1."

More details about each command:


Sometimes, you’ll want to label or “tag” a particular version of your code with some descriptive name. This is often done to label version numbers. For example, when code is delivered to a client, the current version may be tagged “v1.0”. You can “checkout”, i.e., retrieve or copy the version of the code as it looked at the tagged commit.

We will use tags to “turn in” our code. When you tag a particular commit as “v1.0”, you are telling me that you want me to grade that version of code. If you make further changes, you might want to erase the prior tag and tag the newer version of code. Also, be sure to tag the master branch.

You must make a commit before you make a tag. The tag always applies to the most recent commit (and current branch).


(...make some changes...)
git commit -a -m "Some message..."
git tag "v1.0"

If you need to erase a tag, do this:

git tag -d "v1.0"  # use the same tag name; -d means delete

You can also list your tags:

git tag -l

Books and cheatsheets

CSCI 221 material by Joshua Eckroth is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License. Source code for this website available at GitHub.