объедините две или более историй развития вместе (Join two or more development histories together)
TRUE MERGE
Except in a fast-forward merge (see above), the branches to be
merged must be tied together by a merge commit that has both of
them as its parents.
A merged version reconciling the changes from all branches to be
merged is committed, and your HEAD, index, and working tree are
updated to it. It is possible to have modifications in the
working tree as long as they do not overlap; the update will
preserve them.
When it is not obvious how to reconcile the changes, the
following happens:
1. The HEAD pointer stays the same.
2. The MERGE_HEAD ref is set to point to the other branch head.
3. Paths that merged cleanly are updated both in the index file
and in your working tree.
4. For conflicting paths, the index file records up to three
versions: stage 1 stores the version from the common
ancestor, stage 2 from HEAD, and stage 3 from MERGE_HEAD (you
can inspect the stages with git ls-files -u). The working
tree files contain the result of the "merge" program; i.e.
3-way merge results with familiar conflict markers <<< ===
>>>.
5. No other changes are made. In particular, the local
modifications you had before you started merge will stay the
same and the index entries for them stay as they were, i.e.
matching HEAD.
If you tried a merge which resulted in complex conflicts and want
to start over, you can recover with git merge --abort.
