Git Over It

Git is a tool used extensively for open source projects. It is a way of distributing source control instead of the typical central repository. History has it that Linus Torvalds himself developed the original tool.

Every Git working directory is a full-fledged repository with complete history and full revision tracking capabilities, not dependent on network access or a central server.

Why is it called git? The theory is that Linus named it after himself. However, no one seems to know for sure.

Why git? It all started as a dispute between the Linux developers and BitKeeper. The BitKeeper tools had been free to the community until the company charged the developers with reverse engineering their product. The result was that developers would need to pay to continue using BitKeeper. Given the “free” nature of Linux development this obviously did not go down well. Linus led the project to develop an alternative and the result is git.

The overall good news is that git has been widely adopted even though it was only created starting in 2005. There are several good features it has compared to the traditional source control solutions.

Offline changes
Free (always helps)
Fairly simple commands
Distributed source management
Open source (for the hardcore)

To get a better introduction, visit the git homepage. As a set of examples of this homepage:

There is also a section on quick start. Git has two paths for creating a repository. Either it is created from a clone from another server or it is created from scratch.

Anything in parentheses is meant to be replaced with specific actions (like a directory or file). To keep it simple, it is best to experiment with a locally created depot. It is worth doing an easy walk through of the creation.

git init
git add .
git commit -m “My message”

“git init” creates the initial depot for this current project. It creates a subdirectory (usually hidden) called .git which contains all the information that git needs to keep to manage the source. Think of it as being where everything is kept to keep git happy.

“git add .” instructs git to find every single file under the current directory and add it to the staging area to be prepared for committing. It will only add files that are new or changed when used with the “.” which is a great trick. If there are files that you do not want to automatically add, you can always change the “.gitignore” file to skip over them. Typically the object and binaries need to be skipped if the tree is actually built. Doing the add is really just a sign of intent. It does not actually change anything in the git tree. Also of note, if you change any files that have been added, you need to add them again if you want to capture the changes in the staging area.

There is nothing to fear with commitment. Commit with “git commit” just means that you want to capture all the changes into one thing. This is where it updates the local git tree and it is seen as a kind of “snapshot” of where the code is at. Keep in mind that a commit means nothing to anyone else. A commit is just a local thing. This enables git to be used offline and without the need for a central server ever.

However, git can also be used in a distributed team. In fact, that was the original intent. That is the point of the other path for creating a depot on the local machine.

Working off of a remote depot is in this order:

clone a remote depot (git clone)
make changes to the local files (git add)
commit the changes (git commit)
send the patch to someone that cares (git format-patch)

This is not the only way to do it. It is also possible to submit the changes back to the remote depot assuming you have been authorized.

Coming from a world of PVCS and Perforce, git can take some getting used to. It seems uncommon for git to be used in commercial products in Citrix (except for Xen products). XenApp and XenDesktop are based on Perforce.

There are so many different places you can go to find out more about git. Here are some examples: