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.
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 object. Notice how ...