如何在git rebase期间展平合并提交

Question

I have a topic branch which looks as following

* 77a706b
*   4cef576 Merge branch ...
|\
| * 7a13e09 
* | 2fd7265 
|/
* 736cd38 
* 2955a39 f

I'm going to interactive rebase this branch on another parent. How do I flatten the diverged history in the rebase process? I want to get rid of that merge commit, and make the history linear instead (still containing those diverged commits, but not the merge commit itself, as it doesn't introduce any changes)

Answer 1

Well, I don't recommend this approach... in fact, 99% of the time I don't think the desire for a "simpler" history is justified... but if you want to do this, it's pretty much a default behavior of rebase .

If you just start the rebase, as in

git rebase --interactive --onto <new-parent> 2955a39^ 77a706b

you should find that all your non-merge commits are there in the TODO list, while the merge commit itself is gone. By default I believe the rebase will follow the merge's parents in order; I'm not sure about that, but in any event you can reorder the TODO list if need be.

Note that I've assumed here the need for an --onto , because you mentioned that you're moving the commits to a new parent. Whether that's really necessary depends on how the new parent relates to the old one. Let's look at a bigger picture to see the difference:

  P
 /
o -- X -- o -- o -- O <--(master)
      \
       A -- B --- M -- D <--(branch)
             \   /
               C

If you're just moving branch from X to O , then you don't really need --onto ; you can treat master as your upstream because the old branch point is an ancestor of the new parent.

git rebase -i master branch

But if you're moving the branch to an arbitrary parent (which I inferred - perhaps incorrectly - from the phrasing of the question), then that doesn't work. For example to move branch to P requires --onto syntax because if you just used P as the upstream then X would get caught up in the rebase. (This is a simple enough example that you could fix it in the todo list editor; but in general, it's important to remember the difference between an upstream and a newparent .)

Not only is this the default behavior, but overriding it (by supplying the --preserve-merges option) is specifically not recommended for interactive rebases.

So why don't I recommend it? A few reasons.

The big one: if the merge applied any changes, they will be lost. Generally a merge shouldn't apply changes, but there are some gotchas. Obviously if there were merge conflicts, their resolutions are in the merge commit. (This ties into the 2nd reason I don't recommend this, but I'm getting ahead of myself...) If the merge were done with a strategy other than the default, this will read as a change in the merge that gets lost. And "ought to" aside, it's possible someone just created an evil merge for no particularly good reason. If you know none of those things apply, that's well and good...

But then the next reason is that you may well have to do considerable conflict resolution as the "branch" commits are replayed one-by-one over the "mainline" commits. The more commits are on the branch, the bigger an issue this can be.

(In the extreme case: A complaint I hear quite often is, "during a rebase I have to fix the same conflict over and over". Honestly I don't know exactly how that happens, and I've never had an instance of it to fully examine myself (probably in part because I don't rebase for aesthetic purposes), but enough people have said it happens that I have to believe them.)

Lastly, the new commits created by rebase are untested. This may seem unimportant since they're "just intermediate commits", but it does break debugging workflows that depend on bisect.