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.
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:
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