Powered by the Pete

From the ill-informed, to the ill-informed

Git-Svn and Remote Subversion Branches

I’ve been using Git for about two years now as my primary client for working with Subversion.  Git offers me a number of advantages in my day-to-day work, including offline version control, fine grained feature branches, and the ability to package my change sets into single commits before distributing them to my teammates.  I’ve found git-svn’s subversion integration to be quite fluid, and fits with the development workflow process I would use with any version control system.

For instance, here’s my workflow to work on bug X in Subverson:

#Fetch latest from SVN head
svn up

#Create a feature branch for X
svn copy $SVN_ROOT/$CURRENT_BRANCH $SVN_ROOT/$FEATURE_BRANCH
svn switch $SVN_ROOT/$FEATURE_BRANCH

#Commit changes on feature branch X as needed until ready to go
svn ci

#Return to original branch
svn switch $SVN_ROOT/$CURRENT_BRANCH

#Merge all changes on feature branch X, and collapse them into a single change set without committing
svn merge $SVN_ROOT/$FEATURE_BRANCH .

#Fetch any changes since last sync; add commit message as required by company policy
svn up

#Commit all changes to be sent; add commit message as required by company policy
svn ci


Here’s the same workflow using Git-Svn:

#Fetch latest from SVN head
git svn rebase

#Create a feature branch for X
git checkout -b X

#Commit changes on feature branch X as needed until ready to go
git commit -a

#Return to original branch (master)
git checkout master

#Merge all changes on feature branch X, and collapse them into a single change set without committing
git merge --squash X

#Fetch any changes since last sync
git svn rebase

#Commit all changes to be sent to SVN; add commit message as required by company policy
git commit -a

#Push changeset to SVN
git svn dcommit

Note that Git only needs a connection to the remote repository for the rebase and dcommit steps, while Subversion requires a connection for all version control operations. Git also handles the merge operation in the latter case. So far so good.

The most difficult part of working with Subversion from Git is managing remote branches in the repository. The key is to create a remote branch in Git for the branch itself, and then a local Git branch to track that remote branch. Let’s say you have a release-1.0 branch to track fixes to the 1.0 version of your product. This might appear in your Subversion repository as:

$SVN_ROOT/branches/releng/release-1.0

You can add remote branches as you need them with git-svn:

#Tell git-svn where to find the new branch:
git config --add svn-remote.newbranch.url $SVN_ROOT/branches/releng/release-1.0
git config --add svn-remote.newbranch.fetch :refs/remotes/newbranch

#Fetch the remote branch from Subversion
git svn fetch newbranch

#Create a local git branch to track the remote branch:
git checkout -b local-newbranch -t newbranch
git svn rebase newbranch


Now you can jump back and forth between the trunk (master) and the release branch as much as you need to. Since fetch and rebase will import all changes made to each remote branch, you can also use git to handle merges between the branches as well.

Thanks to this post from Stack Overflow for the succinct steps for adding a remote branch.

Advertisements

May 27, 2010 - Posted by | Uncategorized

No comments yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s

%d bloggers like this: