The git svn documentation recommends the following workflow when dealing with Subversion branches:
# Clone a repo (like git clone):
git svn clone http://svn.example.com/project -T trunk -b branches -t tags
# Append svn:ignore settings to the default git exclude file:
git svn show-ignore >> .git/info/exclude
# View all branches and tags you have cloned:
git branch -r
# Create a new branch in SVN
git svn branch waldo
# Reset your master to waldo:
git reset --hard remotes/waldo
# local changes
git add ...
git commit ...
# pull changes on current branch
git svn rebase
# send changes to Subversion
git svn dcommit
# check for new branches
git svn fetch
The workflow above is for an uninterrupted change on a single Subversion branch to which you have the luxury of a commit bit, but juggling multiple active Subversion and git branches is a little tricky.
To track the Subversion repository's waldo branch, start off with
git checkout -b waldo-svn remotes/waldo
The -svn suffix is to avoid warnings of the form
warning: refname 'waldo' is ambiguous.
and also to remind you that this git branch is for tracking the Subversion branch. Always keep changes to these branches linear!
To update waldo-svn, run
git svn rebase
This will fetch the changes from Subversion and rebase any local changes on top of those. It's also smart enough to recognize when one of your local changes has been accepted verbatim upstream: it will be replaced by the Subversion commit and have a line beginning with git-svn-id: ... in its commit message.
When the upstream maintainers alter the contents and structure of your patches (e.g., modifying the code, splitting a patch into multiple Subversion commits, or combining multiple patches into a single commit) is when life gets fun resolving conflicts and trying to untangle the mess.
For full generality, keep your -svn branches in git clean (no changes) and create issue branches off the -svn branches. To send a patch, use
git diff waldo-svn waldo-fix-frobnicator
Then when you git svn rebase to catch up with the Subversion repo, you'll need to review the log and decide on the respective dispositions of your issue branches, sort of a GTD for git.
