Many of you, my readers, do programming for a living. Those who started early used CVS before they switched to Subversion, and there are many who still use it thinking it’s the best this world can offer. We, as lazy beings, look for faster and easier ways to accomplish things. We use version control systems that fit our needs, and personally, I felt that I’m doing the right thing when migrated to Subversion several years ago. So far, working mostly solely on the code base of the projects, I find it sufficient and convincingly simple.

Lately the magical word ”git” made its way into the vocabulary of the programmers community. It’s an SCM system that aids project development in a highly distributed environment and makes all branching and merging chores a breeze. It’s built by Linus Torvalds for the Kernel project and didn’t received any popularity before now for its geeky user interface. Now as the latest develops quickly, the project started to occupy more and more minds. I’m still on the fence, but here are some notes for your consideration.

What I liked to hear:

  • I have all repository locally at any given moment, which makes it easy to diff, commit continuously without waiting for the code to become stable (days and weeks on some complex tasks), work offline (e.g. in the forest or on the sea side – a dream, isn’t it?).
  • The first point also inspires having any number of branches (versions) of the code for testing new features, making refactoring etc
  • The same makes it easy to have any number of repositories for any number of environments separately (dev, stable, production) and to build a flexible workflow around the setup
  • The internal data structures are extremely optimized and take times less disk space than competitive systems
  • The emphasis of the system is on the content rather than on files. A good example is when you move two lines of code from one file to another, git can tell you the migration path of these two lines instead of the changes in two separate files. In other words, content matters more than individual local changes.

What I didn’t like:

  • IMO, multi-node distributed version control may not be worth for mid-sized teams. When there is a single author, it’s great to keep several branches / nodes to test things, work offline etc – it becomes a convenience and aids the development seriously. In large companies with multiple nodes it’s much easier to merge chunks of code and it along is a great plus since none of existing systems handle it easily. For the mid-sized teams, I can see the the maintenance costs defeat the benefits. I must be awfully ignorant, but it’s what my gut says.
  • Even though the content-over-files concept sounds great, I don’t feel really comfortable with it (yet). Probably I just need to go deeper into these waters to judge, but that’s how I feel right now.

Hopefully it gave you some food for thought. See if you find it useful and let’s discuss. Here’s a good place to start looking for more info – Git and Ruby: Git tutorials, articles and links for Rubyists.