Michel Jansen

As a software developer, I am more than familiar with SCM systems like CVS and Subversion. They allow me to work collaboratively on various kinds of projects; from Java to Rails to LaTeX, while providing tools for managing history, conflict resolution and so forth.

All of these more “mature” systems take a very centralized approach: there is one repository and all your base are belong to it. While this may suit companies with a very classic approach to software development, it’s not very flexible for more agile types of development. Meet Git.

Git, like it’s brothers Mercurial (hg) and Darcs, takes a distributed approach to source code management. Instead of forcing you to work in a branch on a centralized server, Git allows you to take the entire repository with you (as a “clone”) and work on it locally. After committing frantically as usual, only to your local repository, you can push back your changes to the source to merge the changes. With Git, it’s no problem having multiple people work at something in parallel.

It’s still a little rough around the edges, but I’m already very enthusiastic about it. I started using it a while back, when I was working at home and had no access to the main CVS repository because it was behind a firewall. It allowed me to keep my changes under version control and made a good impression. My next project is now controlled by Git from the start. Let’s see where that goes :)