The following is from a post by Jim Lindley in 2008. This seems to have from the net, so I’m reposting here (with some amendments) so I have a reference.

Git-SVN workflow

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>

don’t forget the -rXXX where XXX is a recent revision number, otherwise the above command can be very slow

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

Master is current with svn, so 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.

Originally posted by Jim Lindley