So you've probably already heard that Drupal.org is turning to Git for it's version control system (VCS) needs, but you may be wondering, "Well, how do I get into the practice of using Git?". And if, like most developers, you are using Subversion for most of your projects, then I have a really great suggestion on how to start making this transition.

Background

Subversion impaired?

I recently read an article that stated that if you are used to using Subversion for your VCS needs, that you are basically brain damaged! It's a play on an article that compares Mercurial to Subversion, and the concept is really quite similar, being that Git and Mercurial are both distributed VCS systems, while Subversion is centralized. While I'm not sure I would go as far to say you are 'brain damaged', it really is a fundamental shift in thinking.

A basic but imperative concept

The very basic concept you must understand in the difference between Subversion and Git, is that a Subversion repository is hosted remotely and you just have a checkout of the files that are in that repository on your local machine. With Git, you actually get the whole repository locally (hence the term 'clone') and then you also have a checkout of the files that are in that local repository.

Here is a tool to help you transition.

Git-svn

Most development shops use Subversion for their VCS needs. It's not really going anywhere soon, and the transition to a Git world will probably be a little slow, especially if you are collaborating with other shops or people who do not know Git, are unwilling to learn Git, or you just don't have the time/resources to teach or convince them of Git. So if all of your repos belong to SVN, how can you get into the practice of using Git in your daily work life? In steps git-svn. This great tool allows you to work with a remote Subversion repository while using Git on your local machine! You can run all of your normal Git commands locally, merging, branching and even merging Subversion branches (which Git is far superior at doing) all without using Subversion commands and still keeping your remote Subversion repository intact. Other developers can still use it exactly how they are used to, and run Subversion commands if they want... but you will have the real power!

Installation

Installation is pretty simple, but the guys over at MetalToad have already got that covered, as well as some basic commands and cheatsheets, so I'll not go into further detail here.

Typical workflow

My typical workflow when having to collaborate with another team who is using Subversion is as follows:

1. Checkout the code.

$git svn clone <repository-address>
This pulls down the Subversion repository just like $svn checkout would and then puts it into a Git repository locally, adding the original as a remote branch so that you can still push your code back into the original Subversion repository.

2. Make your code changes.
3. Commit your code (purely through Git).

$git commit -am "typical commit message"
This is basically, 'Save'. It commits your changes to your repository, which with Git, is actually on your machine (a main difference between svn and git, as I mentioned). You have not changed anything in the original Subversion repository at this point, everything is still local.

4. Check the repository for changes.

$git svn fetch
$git svn rebase
These two commands are basically the equivalent to doing a $svn up. The first command pulls down any changes that are in the repository, and the second command rewinds any changes you made, applies the new ones it just got from the repository, and then replays your work on top of those changes.

5. Push your code to the remote repository.

$git svn dcommit
For all to all intents and purposes, this command is the basic equivalent to $svn commit -m "typical commit message". It actually does a bit more than that.

From the documentation:

Commit each diff from a specified head directly to the SVN repository, and then rebase or reset (depending on whether or not there is a diff between SVN and head). This will create a revision in SVN for each commit in git. It is recommended that you run git svn fetch and rebase (not pull or merge) your commits against the latest changes in the SVN repository. An optional revision or branch argument may be specified, and causes git svn to do all work on that revision/branch instead of HEAD. This is advantageous over set-tree (below) because it produces cleaner, more linear history.

Conclusion

Git is coming. It's better than you can imagine, and with the imminent approach of Git coming to Drupal, you can finally have everything in one VCS. This is a way to start edging into it, using it in your daily life if you use Subversion regularly now. And CVS? A thing of the past... barely worth mentioning. I for one welcome our new Git overlords!