But enter git-svn which allows me to use git locally and Subversion for the distributed repository.  So now I get the best of both worlds, I can make my local branches and commits, but I don’t have to retrain my team or worry about integration as we still have all of the Subversion interfaces for interacting with the repository.

Using git-svn is pretty simple.  I had to install on CentOS, Max OS X, and Ubuntu and git was available through yum/apt-get/Macports.  To check out was just:

git svn clone http://svn.automattic.com/wordpress/ -ttags -bbranches -Ttrunk

This command will check out all revisions from Subversion and keep a copy of this locally.  Because we download a copy for all revisions, it can take a long time to do this initial setup.

As for the -t/-T/-b, this is used by git-svn to associate SVN branches with git branches.  This configures your git master branch to correspond with the wordpress trunk, but also gives you a git branch for each SVN branch if you want your changes to be tied to a branch rather than the trunk.

One the clone completes, I can use all of the git tools to my heart’s content.  Local checkins, branches, easy merges, etc.  If I need to refresh from Subversion, git will get all new changes from SVN, then replay my edits on top of it.

Committing changes back (assuming that you have permission) just requires:

git svn dcommit

All of your changes are now committed one at a time to the SVN repository.  Very simple for me to get set up and run with.

Digging Deeper…

As I started using git more, I realized how perfect it is for another big problem that I have, managing production configurations.  For example, I have a common problem when managing Apache configurations.  I have the following needs:

• I use multiple conf files to manage my Apache installation (main httpd.conf, virtual host, SSL, etc.)
• I want basic version control over the files to track changes over time
• When trying to debug a problem, I often have to go into the files and tweak multiple debug settings (LogLevel, RewriteLogLevel, etc.).

 What git does for me is lets me do is to create a branch that just contains my debug changes and lets me easily merge the master branch in with these changes.  To do this, I create a debug branch that contains all of my changes needed

git branch debug

git checkout -b debug

..make changes…

git commit

git checkout -b master

… debug is now off…

.. Make changes and commit back to master…

git commit

 ..Now when I need to debug again

git checkout -b debug && git merge master

The merge command will sync the debug branch with the master branch and then will REPLAY the changes that I made to turn on debugging.  When I finish I can turn off my debugging by

git checkout -b master

 I see using this not just to manage logging but in other configuration management problems like:

• Managing database connection information
• Configuring network arrangements