问题
I had two branches both independent. I worked on them at various points over a month. I went to merge one branch (let's call it apple) into the other (let's call it orange) by checking out orange and doing git merge --no-ff apple and everything went fine. In gitk I could clearly see the branches each had their own history and it was merged together in a merge commit on orange.
Later I realize that a commit in orange is incorrect, there is a mistake in the build process, and I must edit that early commit on orange. I use git rebase -i HEAD~19, choose the commit and change pick to edit. So I edit the commit and everything is fine, and I finish the rebase. I go back into gitk and all the history of the two branches is one linear history on orange.
So did I screw something up or is this the way it's supposed to be? I used git reflog to go back to when I did the merge, then I did another reset hard to go back to right before the merge on orange, then I did the rebase and fixed that commit, then after that I did the merge. Now everything looks the way I'd expect where the commits from the branches aren't interlaced together.
For future reference can someone tell me how I can rebase commits on a branch where I've merged in another branch, without ending up with interlaced commits (linear history)?
If my terminology isn't correct feel free to edit this. Thanks again
回答1:
This is expected behavior of rebase. It effectively re-writes the history of the branch, and that causes it to (default) lose merges and other meta-data, leaving a straight, simplified branch.
You can preserve merges by using
git rebase --preserve-merges
but there are some issues with combining --preserve-merges with --interactive. Tread carefully.
来源：https://stackoverflow.com/questions/12966667/git-rebase-ruins-merge