After a little more than a glimpse into the capabilities of Git I am quite impressed!I think I have a quite common background in source code management systems (SCM). I started with CVS at university and I really hated it. On my first job I continued with CVS and started to value a good source code management system.

When you are working with a bunch of guys on a large Java/HTML project you can't work without a SCM system. CVS was a good system with some quite nice GUI clients like the Eclipse CVS plugin or WinCVS.

I am not quite aware when, but it was 2004-2005 I initiated a project to update the SCM infrastructure to Subversion to address some problems with CVS. If you ever created a major release tag on CVS you'll know what I mean
In my opinion Subversion is more than a worthy successor to CVS but it has it's own weaknesses.

The greatest weakness is the lack of branches and tags as an additional dimension in the SCM model. This makes at least branching with SVN not a very nice task. Tracking the changes of files through branches or tags is not that easy, because SVN simulates a branch/tag in the file structure.
On my current job we came across some special SVN related problem. SVN uses the HTTP protocol for communication between SVN client and server. This solves al lot of network related issues, because HTTP is a well known and wide spread protocol. But creates a some new ones. So the synchronization of the working copy can some time, especially for for large binary assets and/or large projects.

But let me emphasize that SVN is a great SCM system with very well tool support (Eclipse, TortoiseSVN, etc.) and a large community. So let's stop SVN "bashing" and start with the real topic.

Git is a relatively new SCM system. It was started in April 2005 by Linus Torvalds. It was created due to the change in license of Bit Keeper, so that the linux kernel developers have no longer access to the SCM system.

The main difference between Git and SVN is, that SVN (like CVS) has a centralized model and Git has a decentralized model. What does this mean? In the SVN world you have one (central) repository which keeps track of all versions. In the Git world you have a local repository which can pull or push versioning data with other (remote) repositories. This has some fancy effects on the Git SCM system:

One thing that puzzled me most during my switch form CVS to SVN was the change in the version number. CVS provides for each file a version number (e.g. 1.1, 1.3.4, etc.) but SVN uses a version number for the whole repository (e.g. 47382). This works only because the is one leading instance (repository). Git does not have this central instance so the Version number is a SHA1 id (e.g. f4d267c9374da99c95222a95e203dab6c15a499). I guess you noticed the difference too But this is necessary because you cannot tell which version (number) this other guy half the way around the world created a moment ago. The version is also provided for a defined set of changes when committed. The version tracks the parent version and so you can build a version tree. This this is quite different the the linear model of SVN, where the version number is an integer.

Another effect of the design is, that there is more emphasis on branching and merging. So the Git provides a lost more support for this tasks. Like git stash which pushes the changes on the working copy into a local branch and restores the HEAD. This is quite nice, if you want to store your work to e.g. fix an urgent problem. Of course you can easily create a new named branch of your stashed changes. Needless to say that merging is quite easy in the Git world. Git also provides a good visualization of the different branches and commits. This makes cherry picking quite easy.

Since I am playing around with Git, I realized how SVN is conceptually weak in branching and merging. A former colleague mentioned this already in 2004 when the migration at my former employer started. I think I understand him now

Another nice feature of Git is that you can fetch versioning informations of SVN. So if you have a central SVN repository, you can push and pull version to this repository and keep track of you local work/changes in Git.

Last topic for this blog entry (yeah, all good things must come to an end ) is the Git tool support. Git is a quite nice command line tool. But sometimes I am quite lazy so I want a GUI tool as well. Eclipse is mandatory for any competitor in the SCM game. Let me mention some real surprise: The EGit Eclipse plugin is the first SCM eclipse plugin (I came across) which could move and rename files and keep track of the version history!
Of course there are various tools for all kind of platforms (e.g. GitX, TortoiseGit or qgit).

I guess, I will keep an eye on Git ...