version control - git svn workflow - feature branches and merge

Question

I am using git-svn with the following workflow now

git clone <SVN TRUNK URL> #done once

subsequently when I work on a feature

git branch featureZ
git checkout featureZ
#make edits for featureZ
git commit

git checkout master
git svn rebase # fetch changes from server

git checkout featureZ #go back to branch
#git merge master 
git rebase master #get the changes from SVN->master onto the branch now. Optional if I want the branch to be current. (EDITED: Got from the answer given below)

#make edits for featureZ
git commit #featureZ completed

git checkout master
git merge featureZ #getting featureZ onto master. Prepare to send to SVN

git svn dcommit #push featureZ back to SVN

Now some points of note when I do git merge of feature onto master, all the individual commits in featureZ branch gets merged as one which is fine with me.

The commit message is replaced as "merged with featureZ". That can be fixed with merge fmt msg.

Now my question is Is there anything that can go wrong with this workflow or needs to be taken care of. I read in git-svn manual that merge should not be done when working with git svn. Is what I am doing in my workflow is what that they are referring to? if so what kind of problem will it cause? One thing is I don't want to do something that messes with the SVN mainline.

Answer 1

SVN cannot handle non-linear history (it simply has no notation of it). So what you want to do is a rebase instead of a merge as it preserves linear history with SVN (this is indicated in on the git-svn man page here.

To elaborate, linear histories are trivial. They go in a straight line (A to B to C to D). Whereas non-linear histories can go from (A to B to C, B to D then C + D to E--in other words, they off sprout into branches).

Rebasing will give you a linear history. Remember that rebases should be done from your private local-only branches. For instances, if you have 2 branches: master and experimental. You would checkout experimental and do 'git rebase master' preferably with the -i flag. Doing it the other way around may result in undesirable side effects.

It is then you checkout master and merge in the changes from the experimental branch. Your history should remain linear.