git svn workflow - feature branches and merge

问题:

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.

回答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.

回答2:

You should look at this merge option:

git checkout master
git merge --squash featureZ

It will squash all commits on the branch into a single commit on the master branch. You will get an opportunity to edit the log message, which is initialized with a summary of what was done on the branch.

It has the disadvantage that the individual commits on the feature branch are not recorded. Furthermore, you should only do this once, and not do any more work on the branch, because it is not registered as a proper merge, and any subsequent merge might give undesired results.

回答3:

The answer given by fake-code-monkey-rashid is correct. This is less of an answer and more of a simplification.

You can svn rebase/dcommit from any git branch. The only use master would have is if you had other local changes you needed to merge with the changes from featureZ.

git branch featureZ
git checkout featureZ
#bunch of changes
git commit
git svn rebase
# solve any conflicts
git svn dcommit

If you want to keep a clean master then you can either git svn rebase it or git merge featuresZ

回答4:

Instead of git-svn, you may use SubGit. It's a server-side tool which automatically synchronizes Subversion and Git repositories.

You can use any Git workflow and any Git client available, no additional client tools needed.

Considering your scenario:

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

You can proceed as follows:

1. Push feature branch entirely.

   git merge featureZ
   git push origin refs/heads/*
   

2. Rebase a feature branch on top of master/trunk.

   git rebase featureZ
   git push
   

3. Squash commits from a feature branch.

   git merge --squash featureZ
   git commit
   git push
   

As soon as you push changes, SubGit hooks translate your changes into Subversion revisions.

Some more details:

• SubGit in many ways is more superior than git-svn — better merge-tracking translation, EOLs & mime-type support, etc.
• SubGit needs local access to Subversion repository (it uses custom hooks);
• SubGit is a commercial product with some free options (open-source and academic projects, small teams).