Reputation: 42
I have a question about Git and merging. I was under the impression that Git merge created a new commit that is the product of all the changes in the diverged history between two branches. And that a rebase just replays changes from one branch to another. But when I was doing some merges today, when I look at my git log it shows that this branch has all the commits from the other branches history as if I had just done a rebase. Can anyone explain why the merge appears to be like a rebase? Or am I mis understanding merge and rebase altogether?
Upvotes: 1
Views: 115
Reputation: 1546
git merge
doesn't create a new commit that is the product of all the changes in the diverged history. It joins two branches. If the merge is a fast forward (that is, if there is no diverging history, and you haven't merged with --no-ff
, then you'll see no extra commits and the history will look as if you'd rebased, since the end effect is the same. If there is divergent history, then a new commit will be created, with more than one parent (one parent per branch that is being merged). Apart from having multiple parents, the commit might include some changes. This usually happens when there are merge conflicts: the merge commit includes the changes that resolve those conflicts.
If you like your merges to be explicit (always having both branches as parents), you can call git merge --no-ff
, which will force the creation of a merge commit, even if it could have been avoided by doing a fast-forward merge.
Upvotes: 3