Git

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.

Git collaboration graph visualisation

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 :)

3 Responses to “Git”

  1. Remko says:

    So the main difference with subversion is that you can commit locally? In other words: You create some kind of local snapshots during your daily work. Besides that it sound really similar.
    And another question: Does it keep your history of changes locally when you have committed to the server? Or are all of these changes synchronized with the host system?

  2. Michel says:

    The main difference is that there is essentially no main server; at least not necessarily. You can push and pull to and from any git repository without losing any history. You always have a local repository containing all the history and when you push the changes to a central server (it is possible to have one) you push all the commits you did locally, not just the current state the project is in.

    Of course, it’s still a SCM, so in many ways it’s similar to subversion. It has some cool extra features like the ability to “cherry pick” changes from a single commit from someone else’s branch, for instance a bugfix. It’s also apparantly better at resolving conflicts and keeping the repository sane, but I don’t really have any personal experience on that end yet.

  3. Pingback: Michel’s Exhaust » Reverting changes in Git

Leave a Reply

Your email address will not be published. Required fields are marked *