GIT-MERGE(1) Git Manual GIT-MERGE(1)NAMEgit-merge - Join two or more development histories together
SYNOPSISgit-merge [-n] [--summary] [--no-commit] [--squash] [-s <strategy>]...
[-m <msg>] <remote> <remote>...
git-merge <msg> HEAD <remote>...
DESCRIPTION
This is the top-level interface to the merge machinery which drives
multiple merge strategy scripts.
The second syntax (<msg> HEAD <remote>) is supported for historical
reasons. Do not use it from the command line or in new scripts. It is
the same as git merge -m <msg> <remote>.
OPTIONS--summary
Show a diffstat at the end of the merge. The diffstat is also
controlled by the configuration option merge.diffstat.
-n, --no-summary
Do not show diffstat at the end of the merge.
--no-commit
Perform the merge but pretend the merge failed and do not
autocommit, to give the user a chance to inspect and further
tweak the merge result before committing.
--commit
Perform the merge and commit the result. This option can be used
to override --no-commit.
--squash
Produce the working tree and index state as if a real merge
happened, but do not actually make a commit or move the HEAD,
nor record $GIT_DIR/MERGE_HEAD to cause the next git commit
command to create a merge commit. This allows you to create a
single commit on top of the current branch whose effect is the
same as merging another branch (or more in case of an octopus).
--no-squash
Perform the merge and commit the result. This option can be used
to override --squash.
--no-ff
Generate a merge commit even if the merge resolved as a
fast-forward.
--ff Do not generate a merge commit if the merge resolved as a
fast-forward, only update the branch pointer. This is the
default behavior of git-merge.
-s <strategy>, --strategy=<strategy>
Use the given merge strategy; can be supplied more than once to
specify them in the order they should be tried. If there is no
-s option, a built-in list of strategies is used instead
(git-merge-recursive when merging a single head,
git-merge-octopus otherwise).
-m <msg>
The commit message to be used for the merge commit (in case it
is created). The git-fmt-merge-msg script can be used to give a
good default for automated git-merge invocations.
<remote>
Other branch head merged into our branch. You need at least one
<remote>. Specifying more than one <remote> obviously means you
are trying an Octopus.
MERGE STRATEGIES
resolve
This can only resolve two heads (i.e. the current branch and
another branch you pulled from) using 3-way merge algorithm. It
tries to carefully detect criss-cross merge ambiguities and is
considered generally safe and fast.
recursive
This can only resolve two heads using 3-way merge algorithm.
When there are more than one common ancestors that can be used
for 3-way merge, it creates a merged tree of the common
ancestors and uses that as the reference tree for the 3-way
merge. This has been reported to result in fewer merge conflicts
without causing mis-merges by tests done on actual merge commits
taken from Linux 2.6 kernel development history. Additionally
this can detect and handle merges involving renames. This is the
default merge strategy when pulling or merging one branch.
octopus
This resolves more than two-head case, but refuses to do complex
merge that needs manual resolution. It is primarily meant to be
used for bundling topic branch heads together. This is the
default merge strategy when pulling or merging more than one
branches.
ours This resolves any number of heads, but the result of the merge
is always the current branch head. It is meant to be used to
supersede old development history of side branches.
subtree
This is a modified recursive strategy. When merging trees A and
B, if B corresponds to a subtree of A, B is first adjusted to
match the tree structure of A, instead of reading the trees at
the same level. This adjustment is also done to the common
ancestor tree.
If you tried a merge which resulted in a complex conflicts and
would want to start over, you can recover with git-reset(1).
CONFIGURATION
merge.summary
Whether to include summaries of merged commits in newly created
merge commit. False by default.
merge.verbosity
Controls the amount of output shown by the recursive merge
strategy. Level 0 outputs nothing except a final error message
if conflicts were detected. Level 1 outputs only conflicts, 2
outputs conflicts and file changes. Level 5 and above outputs
debugging information. The default is level 2. Can be overridden
by GIT_MERGE_VERBOSITY environment variable.
branch.<name>.mergeoptions
Sets default options for merging into branch <name>. The syntax
and supported options are equal to that of git-merge, but option
values containing whitespace characters are currently not
supported.
HOW MERGE WORKS
A merge is always between the current HEAD and one or more commits
(usually, branch head or tag), and the index file must exactly match
the tree of HEAD commit (i.e. the contents of the last commit) when it
happens. In other words, git-diff --cached HEAD must report no changes.
Note
This is a bit of a lie. In certain special cases, your index is allowed
to be different from the tree of the HEAD commit. The most notable case
is when your HEAD commit is already ahead of what is being merged, in
which case your index can have arbitrary differences from your HEAD
commit. Also, your index entries may have differences from your HEAD
commit that match the result of a trivial merge (e.g. you received the
same patch from an external source to produce the same result as what
you are merging). For example, if a path did not exist in the common
ancestor and your head commit but exists in the tree you are merging
into your repository, and if you already happen to have that path
exactly in your index, the merge does not have to fail.
Otherwise, merge will refuse to do any harm to your repository (that
is, it may fetch the objects from remote, and it may even update the
local branch used to keep track of the remote branch with git pull
remote rbranch:lbranch, but your working tree, .git/HEAD pointer and
index file are left intact).
You may have local modifications in the working tree files. In other
words, git-diff is allowed to report changes. However, the merge uses
your working tree as the working area, and in order to prevent the
merge operation from losing such changes, it makes sure that they do
not interfere with the merge. Those complex tables in read-tree
documentation define what it means for a path to "interfere with the
merge". And if your local modifications interfere with the merge,
again, it stops before touching anything.
So in the above two "failed merge" case, you do not have to worry about
loss of data --- you simply were not ready to do a merge, so no merge
happened at all. You may want to finish whatever you were in the middle
of doing, and retry the same pull after you are done and ready.
When things cleanly merge, these things happen:
1. The results are updated both in the index file and in your working
tree;
2. Index file is written out as a tree;
3. The tree gets committed; and
4. The HEAD pointer gets advanced.
Because of 2., we require that the original state of the index file
to match exactly the current HEAD commit; otherwise we will write
out your local changes already registered in your index file along
with the merge result, which is not good. Because 1. involves only
the paths different between your branch and the remote branch you
are pulling from during the merge (which is typically a fraction of
the whole tree), you can have local modifications in your working
tree as long as they do not overlap with what the merge updates.
When there are conflicts, these things happen:
1. HEAD stays the same.
2. Cleanly merged paths are updated both in the index file and in your
working tree.
3. For conflicting paths, the index file records up to three versions;
stage1 stores the version from the common ancestor, stage2 from
HEAD, and stage3 from the remote branch (you can inspect the stages
with git-ls-files -u). The working tree files have the result of
"merge" program; i.e. 3-way merge result with familiar conflict
markers <<< === >>>.
4. No other changes are done. 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.
After seeing a conflict, you can do two things:
· Decide not to merge. The only clean-up you need are to reset the
index file to the HEAD commit to reverse 2. and to clean up working
tree changes made by 2. and 3.; git-reset can be used for this.
· Resolve the conflicts. git-diff would report only the conflicting
paths because of the above 2. and 3.. Edit the working tree files
into a desirable shape, git-add or git-rm them, to make the index
file contain what the merge result should be, and run git-commit to
commit the result.
SEE ALSOgit-fmt-merge-msg(1), git-pull(1), gitattributes(5)AUTHOR
Written by Junio C Hamano <junkio@cox.net>
DOCUMENTATION
Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
GIT
Part of the git(7) suite
Git 1.5.5.2 10/21/2008 GIT-MERGE(1)