Initial Thoughts On Git

Four years ago I moved the development team at my current company from Visual SourceSafe to Subversion. I had been using SourceSafe at my current company and a previous employer for about ten years total.  Our SourceSafe was at times painfully slow, and I knew of some of the issues SourceSafe had with possible data corruption. At the time I was reading a several books from the Pragmatic Bookshelf, so picking up “Pragmatic Version Control with Subversion” made sense.  There were two core improvements I was looking for.  First, I wanted a product that could handle merges better from the start the SourceSafe. Second, I needed something that would work in both a Windows and Unix environment, because our Unix code badly needed source control.  To me Subversion made perfect sense, and seemed like the best option at the time.

Another developer mentioned Mercurial, and I spent a little bit of time researching it.  I recall having a hard time understanding how a distributed version control system made much sense.  I saw the central repository being the core feature in a VCS, and had not read enough to really understand how distributed version control really worked.  In retrospect I can also see that since most of our projects were solo projects, some of the core advantages of being distributed would not have been realized.  I also doubt I could have gotten my boss at the time to buy into using a distributed VCS.

Over the past several years, Git started to show up on the blogs I follow with more and more regularity.  When the Pragmatic Bookshelf had a sale in November of last year, I decided to pick up “Pragmatic Guide to Git”. This month I finally managed to crack it open, and run through the fabulous Git Immersion site by EdgeCase.  I have some initial thoughts on Git as compared to what I have used in the past.

The first thing I like is that tagging makes sense. Subversion’s paradigm of making a copy always felt a little off to me. This is much cleaner in Git, feels more natural, and seems like it will be easier to understand.

The second thing that interests me is the flexibility. If you want to run it as a centralized version control system it is possible. Individual developers would still have the option to use all the features that Git brings to the table.

There are some advantages that come from being a distributed VCS.  There is the obvious advantage of being able to work offline.  Easy integration with offshore resources is a possible huge win.  I had a moment last week where I thought how much simpler something we were doing would have been if we were using Git with an offshore resources.

Git seems to remove some of the friction that I felt when I was setting up Subversion for some solo projects.  In place branch switching and two stage commits seem useful, but I won’t know how useful until I’ve had a chance to use Git a little more.

Overall it seems as though Git (and other distributed VCSs) are source control for the developer.  It gives the developer a lot of power to easily create experimental branches on their code base.  It allows them to have a ton of small commits, and then share them back to the master with less friction for the other developers.

For my current company, Git seems like a less than optimal fit.  We don’t have large enough teams to get much advantage of the merging and distributed nature. I would not have a problem with someone using it to supplement our central control system (right now transitioning to TFS to leverage work item tracking in TFS).  This is especially on the Unix side, and I would want to evaluate using something like Git-TFS bridge as well.