Git is a versatile Distributed VCS, and unlike a Centralized VCS (i.e Subversion), many different versioning workflows are possible. This section will describe the recommended Git workflow for EECS coursework, and detail how to get it up and running on EECS systems.

Note: This How-To is written for use on EECS Linux Workstations and Cycle Servers.

Git repositories are easily created, and it is recommend that you create a new one for each new project that you want to have version controlled. Below is a diagram representing the recommended Git workflow for EECS coursework.

In this setup you have two git repositories for any given project. A private repository, which is your “working copy”, where you do all of you work and testing. In addition to that, you have a public repository, your “pristine copy”, which only includes finished and tested code. Note: Only your public repository is accessible to others.

For example, say I'm working with you on a project. I have finished writing a core class and want to make it available to you.

1. I would commit my changes to my private repository.
2. Then I would push those changes to my public repository to make them available to you.
3. You would pull down those changes to your private repository to begin using my new class in your code.

The following sections will detail how to setup the Git workflow described above on EECS systems, but will not inform you on the general use of Git. If you are unfamiliar with Git and it's basic commands read the Git Basics chapter of the Git manual.

To create an empty private repository run the following command.

git init ~/new/project/location

To create a private repository from an existing directory, run…

git init ~/your/project/location

From here you can add and commit changes to your private repository. Again, if you are unfamiliar with Git and it's basic commands read the Git Basics chapter of the Git manual.

Note: If you are working on an individual project, it still benefits you to use Git, as it will help you track changes, and recover from mistakes. In this case you only need a private repository, and do not need to bother setting up a public repository.

If you are working on a group project and want to use Git repositories to collaborate and manage the project with your group-mates you will need to create a public clone of your repository. Your public Git repositories should be located in the ~/public_html/git directory of your home directory.

Note: If the ~/public_html/git directory does not exist create it

mkdir ~/public_html/git

To create a public copy of your repository execute the following commands from the root directory of you private repository.

1. Create your public repository.

   git clone --bare ./ ~/public_html/git/[project_name].git

2. Tie your private repository to your public repository.

   git remote add origin ~/public_html/git/[project_name].git

3. Change directories to you public repository.

   cd ~/public_html/git/[project_name].git

4. Enable some automated maintainance.

   cp hooks/post-update.sample hooks/post-update 

5. Clean up public repository.

   git update-server-info

Now you can push changes from you private repository to your public repository.

By default, your public repositories are not accessible to others. To make them accessable follow the instructions below to create an .htaccess file that will grant group-mates access.

DETAILS COMING SOON

To pull down a group-mate's changes you must add their public repository to your private repositories list of remote repositories.

cd ~/your/private/repository/location

git remote add [name] http://people.eecs.ku.edu/~[username]/git/[project_name].git

Once this has been done, you will be able to pull down change from your group-mates public repository using the following command.

git pull [name] master

This command will fetch and merge your working copy with that of your group-mates. Git merges intelligently, but sometimes there are cases were a merge will create a conflict. To learn more about branches and how to resolve merge conflicts read the Git Branching chapter of the Git manual.