Do you love Git? Are you working on a project that’s using Subversion? Well, did you know that Git actually integrates quite nicely with Subversion right out of the box? I’ll show you what you need to know to get started with Git and Subversion, and I’ll show you the workflow I use for keeping my work in sync with everyone else on my team.
Getting Git
The easiest way to get started with Git on Windows these days is to install Git Extensions. The installer will push everything you need to your computer. As a nice bonus, Git Extension has a very slick UI. Unlike TortoiseGit, which incorrectly tries to make Git feel like Subversion, Git Extensions is actually designed to support Git and all its many operations.
During the install, be sure to tell it to “Check Out As-Is, Commit As-Is.” From my experience, that’s the least painful way to use Git. I would also recommend choosing the “Run Git from the Windows Command Prompt” setting as that will allow you to use posh-git once you’re ready to try out Git from the command line (which I highly recommend).
Cloning From Subversion
Right out of the box, Git has the ability to clone a Subversion repository. You don’t need to install any additional addons (like you do with git-tfs). If you installed Git using Git Extensions, you’re already set up. This is such a common Git scenario that the Pro Git book actually has a chapter on it. I recommend reading “Git and Subversion” now to get a basic understanding.
Assuming the Subversion repo you want to clone follows the standard SVN conventions (having a /trunk, /tags, and /branches folders), cloning the repository is a simple command:
git svn clone http://path_to_your_repo -s
The “-s” parameter tells git that the repo follows the standard conventions. Note that this command might take some time. Git isn’t going to just pull down the latest revision, it’s going to pull the entire history from the repository. “OH CRAP” I hear you saying. “WON’T THAT BE HUGE?!?!” While your mileage may vary (it depends on the types of files and commits in your repo), from my experience, a Git repo with full history is around the same size as a Subversion working copy. Let that sink in for a second. A git repository, which includes a local copy of the entire history of the repository, won’t be much (if any) bigger than an SVN working copy that contains a single revision. How awesome is that?
My Git SVN Workflow
My workflow is actually derived from Jimmy Bogard’s git-tfs workflow. My master branch remains clean and always reflects what’s in SVN only. I always do my work in a feature/topic branch, then commit to SVN from that branch when I’m finished. Here’s what a session might look like:
git checkout master git svn rebase git checkout -b feature-branch /* Work work work */ git add -A git commit -m "Implementing super-awesome feature!" /* Now to be sure I still have the latest code from SVN */ git checkout master git svn rebase /* Now I rebase my feature branch so that it has the latest... */ git checkout feature-branch git rebase master /* And finally, I push my changes to SVN. */ git svn dcommit /* And I'm done! */ git checkout master git svn rebase git branch -d feature-branch
It’s not as daunting as it looks, and this workflow makes it easy for me to jump in and out of work on a feature as needed.
The ‘git svn dcommit’ command will actually create one SVN commit for each git commit that you made in your feature branch. One thing I’m playing around with is collapsing my work before committing it to SVN, that way my intermediate commits don’t clog up SVN with useless noise. Instead of committing from my feature branch, I create a new branch directly from master, then merge in my feature branch with the “--squash" argument. I’m not sure if I like this approach yet or not…
Go Try It Out!
Git is an amazing tool. While there are certainly some “gotchas!” you need to be aware of (read the book!), I have found that Git makes a great client for working with Subversion. At this point, I don’t miss TortoiseSVN at all. 