This is my current git-svn workflow:
git checkout -b feature master
# hack commit hack 开发者_如何转开发commit
git checkout master
git svn rebase
git merge feature
git svn dcommit
This usually works fine, git replays at the trunk all the commits from the local branch, and the only 'lost data' are the original commit's timestamps, no big deal.
But it looks like today there was something different about the merge and dcommit that caused the commit message on the SVN repo to be simply "Merge branch 'feature'", maybe because the feature was 'smaller', with only 2 or 3 commits.
How can I avoid this to happen and ensure that all commits and commit messages from git are replayed on the SVN repo?
That comment should be the result of a dcommit of a git merge, as illustrated in "Is git-svn dcommit
after merging in git dangerous?":
(master)$> git log --graph --oneline --decorate
* 56a779b (work, master) Merge branch 'work'
|\
| * af6f7ae msg 3
| * 8750643 msg 2
| * 08464ae msg 1
|/
* 21e20fa (git-svn) last svn commit
In other words, if those three "msgx
" commits had been done directly on master, they would have been replayed (with their original comments) on the svn side.
But here, only the resulting merge commit gets replayed, with the "generic" comment on it.
You will need to rebase from the feature branch first:
git checkout feature
git rebase master
This ensures that when you merge into your master, you only get a Fast-Forward rather than an actual merge.
My flow is usually more like this:
git checkout master
git svn rebase
git checkout feature
<hack...hack...hack>
git commit
git rebase master
git checkout master
git merge feature
I just make sure to do an svn rebase and then rebase all my feature branches to keep everything nice and linear the way that SVN likes it.
Also, if you're not aware of it, there is the git svn dcommit --dry-run
option. I always use --dry-run
and count the number of commits to make sure that git-svn is going to commit what I expect.
精彩评论