What is Git and why might I consider using it?

This question has come up from a couple of customers. Many of you are using products such as Microsoft Team Foundation Server (TFS) or older source code control systems like Subversion.

For these Iguana Apps we’re, using GitHub as the repository to manage the source of these applications. As of today the Channel Manager application is not tightly coupled to Git. The Channel Manager has a very simple design: it just dumps files into what it sees as a plain old directory.  There is no special interface with Git.

So, as of today, you can take the Channel Manager and use it with whatever source code control system you happen to love.

For us using Git is an experiment. Git seems to be the eco-system winner of the next generation of source control, which tilts overwhelmingly toward distributed systems. Microsoft even put support for Git into Visual Studio. These systems emerged out of the model pioneered by Bit Keeper. (There is a controversial story behind how Git came to be with the dynamics of what happened with Bit Keeper and the Linux kernel development community.) Some of the systems competing with Git are Mercurial and fossil.

Within Iguana we use fossil. Its big advantage is that it’s a very light weight system that is easy to deploy; it’s just a single executable with next to no dependencies. This is why we picked it for inside of Iguana. It does not have the same strength of ecosystem that Git has, though. For the last couple of years we’ve been using Mercurial internally as our enterprise source code control system. It’s been okay – we love the ability to easily branch which is a feature of all these systems – but we do find it a bit sluggish. That could be our own fault, a byproduct of how we have it configured, but it’s never a bad idea to learn about alternatives.

So, yes, using Git for this project is a bit of an experiment. So far we’re enjoying it. Git is a little more complicated to use than, say, fossil, but it seems very snappy compared to Mercurial. Then, that may be an unfair comparison since we have millions of lines of code in our Mercurial repository, and these apps are only getting started.

I really am impressed with what GitHub offers. Please realize that Git != GitHub. Git itself is a free open source product that you can use without license fees. GitHub is a commercial business which offers hosting of Git repositories in the cloud. GitHub provides a lot of nice features with respect to managing your projects on top of plain Git. It has all the neat graphical features that you see.

They offer paid plans which allow you to use their service for commercial non open code.

So should you use Git? Good question. I am asking myself the same question.

It’s really up to you. If you’d like to dabble and get a feel for it, then you can do that very easily just like us with this project. If you prefer to stick with your existing solution then you can do that also. In fact, if wanted to write better bindings for the Channel Manager which would interface nicely with, say Microsoft TFS, we’d be happy to take the patch. It’s probably much less effort for you to piggy back off our efforts here than to reinvent the wheel completely internally.

For us our plan is to continue to work with GitHub for this project, learn it and really spend some months understanding if it’s a good choice for us. So far I like what I see. The GitHub interface is fast and intuitive and the price is competitive with the hosted service we use for our Mercurial repository.