How Git Thinks About Merges
At first, Gitâs automatic merging support seems nothing short of magical, especially compared to the more complicated and error-prone merging steps needed in other version control systems.
Letâs take a look at whatâs going on behind the scenes to make it all possible.
Merges and Gitâs Object Model
In most version control systems, each commit has only
one parent. On such a system, when you merge
create a new commit on
my_branch with the changes
some_branch. Conversely, if you merge
creates a new commit on
some_branch containing the
my_branch. Merging branch A into
branch B and merging branch B into branch A are two different
However, Git designers noticed that each of these two operations
results in the same set of files when youâre done. The natural way to
express either operation is simply to say âMerge all the changes
another_branch into a single branch.â
In Git, the merge yields in a new tree object with the merged files, but it also introduces a new commit object on only the target branch. After these commands:
git checkout my_branch$
git merge some_branch
the object model looks like FigureÂ 9-10.
FigureÂ 9-10.Â Object model after a merge
In FigureÂ 9-10, each
C is a commit object
T represents the corresponding tree ...