I have finally made some time to check out Git. For the past couple of days I’ve been experimenting with Git to see if it is something that we should use at Realeyes Media. The following is my Git story as well as some of the resources that I gathered along the way.
First things first, “git” initiated if you don’t know what Git is.
Now, our requirements to switch over to Git:
- A quick learning curve
- A simple shared development model – Less branch and merge pain than SVN
- We need a central location for all major projects and we would like to host it
- It needs to work with a Continuous Integration tool – we use currently Hudson
- We needed a reason – Is it simpler? Is it faster? Basically does it solve any problems we had with SVN?
Requirement #1: The learning curve
Yep, no problem. If you are used to SVN, you’ve got it made. Retrieving project code, making changes and committing are all pretty straight forward. Managing the repository does require a bit of a perspective shift though. With SVN the HEAD of the repo lives in one place – on the server. Git is a “distributed” system so each developer has a local copy of the development history. It is an easy perspective to change to and Git is flexible enough to fit into the central repository schema (more on this later).
Sample Git commands:
1. Get project code
$ git clone git://git.server.com:projectName.git
[Make some changes]
2. Commit changes
then
$ git commit -am 'Your commit message.'
Requirement #2: A flexible shared development model
Getting project code is simple and straight forward. Making changes and committing to your local repository is easy. Now how does a developer handle sharing changes and integrating others changes into their local repository? There are a few ways to set up shared development. Two that Realeyes is considering are (for more info on share development check out the Git documentation):
- Patch-based collaboration where patch files are sent via email and then integrated into the repository by the maintainer. Because the patches are read and reviewed by many people (everyone on the mailing list hopefully) this can provide a “first line of defense” against bugs.
- Repository-based collaboration where changes are pushed and pulled from a centrally located repository. This can decrease the overhead for the maintainer, but can also add some overhead for the maintainer as well as overhead for any continuous integration systems.
Branching and merging are two important concepts of shared development. With Git these operations are part of hte daily work-flow and are simple and accurate. Git is smart. It handles much of the heavy lifting having to do with merges for you because the development history is tracked with every branch – even with changes across branches that are being merged into master (trunk for you svn’ers).
Requirement #3: Central Location and Hosting
This is partially addressed in #2 if we use repository-based collaboration. Setting up a remote Git server can be as simple as setting up a server with SSH and creating repositories from there. You can also set up repository access with the GIT protocol as well as HTTP and WebDAV for public and restricted access – so we have options. This is where I spent a bunch of time (just because I thought it was fun), setting up different servers and configurations (Windows & Ubuntu, SSH, HTTP etc) to make sure that we could host our own Git remote repositories without issue. Here are a few of the resources that got me going quickly:
Requirement #4: Continuous Integration
This one was simple, I found plenty of information to confirm that Git will work with Hudson as well as CruiseControl (another CI system we’ve used in the past).
Requirement #5: We Need a Reason
Now that I’ve had a couple of days to play with Git, experienced its flexibility and discover the improvements it has over SVN, I think that we have plenty of reasons to start using Git. Here are some of the standout reasons in my mind:
- Git operations are just as easy (if not easier) to learn and remember as SVN commands
- Simplified shared development: Every developer has a copy of the development history – they can work no matter what the status of their internet connection is.
- Branches and merges are simpler and easier because branches come along with their entire history
- Cleaner project directories: There are no ‘.svn’ directories in every project folder, everything is stored in one ‘.git’ directory at the root of your repository
- SSH Security as well as multiple delivery options: HTTP, GIT WebDAV
- Performance: Git is fast
In short, I really like Git. It is a lighter, more efficient and a simpler workflow than SVN. So, SVN old friend, you have treated us well (except for the merges), I think it is time to step back and make a little room for Git.
Following is the list of links that I’ve used in this post as well as to get me up to speed for my “Git Expedition”.
Guides and Docs:
Tutorials and Resources:
Git GUIs:
Read More
For quite some time now the Realeyes development queue has been taken up with the new 
