Jim Lindley Notes

The canonical git-svn workflow that I’ve seen goes like this:

git svn clone <svn_repo>
git checkout -b <work_branch>
    ...hack...hack...
git commit -a
git checkout master
git svn rebase
git merge <work_branch>  #NOTE: no need for --squash anymore
git svn dcommit -e  # -e will let you enter a commit message for SVN

I’ve had more luck with the following workflow, when integrating changes via SVN from other team members:

# initial setup
git svn clone <svn_repo>

# 99% of daily workflow
git checkout -b <work_branch>
    ...hack...hack...
git commit -a

# switch back to master, then rebase against
# any revisions in the svn repo
git checkout master
git svn rebase

# now that master is current with svn,
# sync working branch to local master
git checkout <work_branch> # These two are the added steps
git rebase master          # which help prevent conflicts

# final upstream commit after rebasing
git checkout master
git svn rebase # one last check for new svn check ins
git merge <work_branch>
git svn dcommit -e

The extra rebase step seems to do a better job of integrating your patches into the tree. Merge should do the same thing, if I’m reading the man pages right, but splitting the steps is more idiot proof (me-proof) this way.

It also keeps the master local branch from getting messy dealing with conflicts. Instead conflict is kept in the side working branch.