Will this git-svn workflow work?

Question

I'm experimenting with git-svn, and am trying to come up with a relatively non error-prone workflow. I think the following should work, and is pretty simple, but I've seen people using far more complicated workflows, so I want to see why.

1. (master) $ git svn init <path>
2. (master) $ git svn fetch
3. (master) $ git svn rebase
4. (master) $ git checkout -b topic-branch
5. (topic-branch) $ # HACK HACK COMMIT HACK HACK HACK COMMIT HACK COMMIT
6. (topic-branch) $ git checkout master
7. (master) $ git merge topic-branch -- this is a fast-forward merge, so no merge commit
8. (master) $ git svn rebase
9. (master) $ # fix conflicts
10. (master) $ git svn dcommit
11. GOTO 4

Answer 1

From my brief experience I've made minor adjustments to your workflow and added comments:

1. (master) $ git svn init <path> (or (master) git svn clone <url>)
2. (master) $ git svn fetch
3. (master) $ git svn rebase (begin loop, resolve conflicts)
4. (master) $ git checkout -B topic-branch (careful before doing this)
5. (topic-branch) ## HACK HACK COMMIT HACK COMMIT (use 3rd party)
6. (topic-branch) $ git checkout master
7. (master) $ git rebase topic-branch (resolve conflicts)
8. (master) $ git svn rebase (resolve conflicts, if any)
9. (master) $ git svn dcommit (careful reading here)
10. GOTO 3 (or 4 if no need to rebase again)

I'm using master branch just for integration with SVN and doing all work on topic-branch, just like I believe you were. I hope this makes more sense, since I couldn't use your workflow the way it was even if it was basically what I wanted - evidently! :-)

More details on the adjustments that were made:

• Attention to capital -B on step 4, it will reset the topic-branch so it's always new from current SVN. without it the loop would break giving an error "branch already exists".
• Step 7 using rebase rather than merge. yes, it will probably be a fast-forward merge, but it's better safe than sorry. picture if something is done between steps 6 and 7.
• Loop to 3 instead of 4. Also, just to play on the safe side. Seems like using svn rebase never is an abuse and since it's always done on master there's always branches as backup.

Answer 2

It is safe if you while doing steps 5 never switch to master and do "git svn rebase". Else i would recommend doing a "git rebase master" between steps 5 and 6.

Answer 3

Yes, that's essentially what I do when working with Subversion repositories. The key to the simplicity of this is to keep the Git branches local and not try to map them to Subversion branches at all.

I just noticed that you linked directly to my answer in that other question. So perhaps I should explain more. :)

I sometimes do the conflict resolution in the topic branch if I expect some conflict work. Otherwise, if I don't expect many conflicts, I might merge to master first before doing the git svn rebase. It doesn't matter much.

The key point is that Git is so flexible that the minimum workflow is very simple. You've added a topic branch to that; I've added rebasing on the topic branch.