This document is intended to serve as a basic guide to help you use git for source control for your 482 projects. It is not intended to be a thorough reference. Several of git's features are omitted in this document since they aren't likely to come in handy for 482 projects.
Git is well supported on Linux, Mac and Windows. For 482, you will most likely be working in a Linux environment. This document therefore goes over using git on Linux specifically. If you wish to get yourself set up with git on other platforms, look around on the web, or talk to one of the instructors.
Git is a distributed source control system. This is in contrast to more traditional centralized source control systems like Subversion, CVS, Perforce etc. There is a significant difference in the way distributed source control systems are used. Here is a brief summary.
In a centralized source control system, you have one repository that tracks history. You then have multiple "working copies" which you use to work in. You then commit your changes to the central repository from which your teammates can get your changes.
In a distributed source control system, there is no necessity for a central repository. When you create a repository, you use it to work in, and it tracks history for itself. There is no notion of "working copy". You can however clone repositories, and push to and pull from clones. The major difference here is that you can work in your local repository, make commits and have them stay local to you. You do not need be online and have access to the central repository to commit your changes. The way git is typically used is that each person working on the project has their own repository to which they commit. When person A wants to get the changes person B has made to the project, person A pulls person B's changes into person A's repository. Therefore, each person has their own "latest" revision, unlike in a centralized source control system.
This system is not ideal for 482 because your team needs to have one submission quality version. Therefore, this guide goes over how you use git in a centralized way. There are a couple of advantages of doing this instead of using Subversion or CVS.
1. Since your repository is local to you and has full revision tracking abilities, you can make as many commits as you want, and not have to force your teammates to get your changes. What this means is that you can commit very frequently without your code being "functional". When you are reasonably sure that your code is functional enough that it will not disrupt your teammates' work, you can push it to the central repository, from which they can pull your changes. If you were using Subversion and committed broken code, your teammates would either have to fix it, or wait for you to fix it before they can commit their changes. More often than not this will lead to massive, and infrequent commits, which beats the point of source control.
2. Git offers quick and easy branching. While you will probably not need to branch for 482 projects, this is a feature worth getting acquainted with. More on branching follows later in the document.
First, you need to set up your central (aka "remote") repository. You will need to give your teammates access to this repository so they can pull from and push to it. Below are the comamnds to do that. (You can also assign access permissions via MFile if you prefer to do it that way).
For the rest of this document, it is assumed that your uniqname is "uniqname", and your team mates' uniqnames are "uniqname1" and "uniqname2".
$ cd ~/Shared
$ mkdir 482Projects.git
$ fs setacl 482Projects.git uniqname1 rlidwk
$ fs setacl 482Projects.git uniqname2 rlidwk
$ cd 482Projects.git
$ git --bare init
What you have just created is a "bare" repository. What this means is that it only stores deltas and other git specific binaries. You cannot work in this repository. A normal git repository is also a working directory and the git specific information is stored in the .git directory. Therefore, what you would see in a normal repository's .git directory you will see in this bare repository. You will need to create a normal repository that contains the actual files and push to this central repository. Below are commands to do that:
$ cd ~/Desktop
$ mkdir My482Repo
$ cd My482Repo
$ git init
$ touch README
$ git add README
$ git commit -m 'First commit.'
$ git remote add origin /afs/umich.edu/user/u/n/uniqname/Shared/482Projects.git
$ git push origin master
Once all of the above is done, your teammates can clone the central repository. Here's how they do that:
$ git clone /afs/umich.edu/user/u/n/uniqname/Shared/482Projects.git My482Projects
Once you and your teammates have your clones set up, you should be set to go. Each of you will now be able to pull from, and push to the central repository.
Committing files to a git repository is similar to how things are done in Subversion. You add a file to be tracked using the "git add" command. For example:
$ touch disch.cc
$ git add disch.cc
$ git commit
$ git push
After you enter the "git commit" command, your default text editor will be opened. This is where you type your commit message. A recommended practice is to enter a brief summary in the first 80 characters. You can then write more commit info in the next paragraph. You can also pass in the commit message as a command line argument. Here's how:
$ git commit -m "Commit message."
Note that typically, you will commit multiple times before you push.
You can pull changes from the remote repository to your local repository via the "git pull" command. You should frequently pull from the central repository to make sure you are up to date with your teammates' work. Here's how you pull:
$ git pull
One of the most advertised features of git is branching. Git allows quick and easy branching and merging. You probably won't need to branch for your 482 projects. However, it is a feature worth looking at. Here is a good resource that shows you how to create a remote branch and track it locally. If you are not familiar with the concept of branching, here is a quick summary. A branch is essentially a "line of development". By default in git, you work on the "master" branch. If you wish to try something on an experimental basis, you can create an "experimental" branch and use that as a parallel line of development. The changes you make on the "experimental" branch will only appear there. If you switch back to the main branch, you will not see those changes. You can have multiple branches, and merge one branch into another. Git makes all of this very easy to do. For more on this, search on the web, or talk to an instructor.
As mentioned earlier, this document omits a lot of features git has to offer. There are several great resources on the web that can help get you acquainted better with git. Here is one of them. Here is one that was written for the U-M HKN EECSSpeaks newsletter. Do a bit of searching and find the one that you like best.
You may also find this to be an entertaining video to watch. It is an interesting (and biased) view on why you should use git.