1GIT-MERGE(1) Git Manual GIT-MERGE(1)
2
6 git-merge - Join two or more development histories together
7
9 git merge [-n] [--stat] [--no-commit] [--squash]
10 [-s <strategy>] [-X <strategy-option>]
11 [--[no-]rerere-autoupdate] [-m <msg>] <commit>...
12 git merge <msg> HEAD <commit>...
13
16 Incorporates changes from the named commits (since the time their
17 histories diverged from the current branch) into the current branch.
18 This command is used by git pull to incorporate changes from another
19 repository and can be used by hand to merge changes from one branch
20 into another.
21 Assume the following history exists and the current branch is "master":
23 A---B---C topic
25 /
26 D---E---F---G master
27 Then "git merge topic" will replay the changes made on the topic branch
30 since it diverged from master (i.e., E) until its current commit (C) on
31 top of master, and record the result in a new commit along with the
32 names of the two parent commits and a log message from the user
33 describing the changes.
34 A---B---C topic
36 / \
37 D---E---F---G---H master
38 The second syntax (<msg> HEAD <commit>...) is supported for historical
41 reasons. Do not use it from the command line or in new scripts. It is
42 the same as git merge -m <msg> <commit>....
43 Warning: Running git merge with uncommitted changes is discouraged:
45 while possible, it leaves you in a state that is hard to back out of in
46 the case of a conflict.
47
49 --commit, --no-commit
50 Perform the merge and commit the result. This option can be used to
51 override --no-commit.
52 With --no-commit perform the merge but pretend the merge failed and
54 do not autocommit, to give the user a chance to inspect and further
55 tweak the merge result before committing.
56 --ff, --no-ff
58 Do not generate a merge commit if the merge resolved as a
59 fast-forward, only update the branch pointer. This is the default
60 behavior of git-merge.
61 With --no-ff Generate a merge commit even if the merge resolved as
63 a fast-forward.
64 --log, --no-log
66 In addition to branch names, populate the log message with one-line
67 descriptions from the actual commits that are being merged.
68 With --no-log do not list one-line descriptions from the actual
70 commits being merged.
71 --stat, -n, --no-stat
73 Show a diffstat at the end of the merge. The diffstat is also
74 controlled by the configuration option merge.stat.
75 With -n or --no-stat do not show a diffstat at the end of the
77 merge.
78 --squash, --no-squash
80 Produce the working tree and index state as if a real merge
81 happened (except for the merge information), but do not actually
82 make a commit or move the HEAD, nor record $GIT_DIR/MERGE_HEAD to
83 cause the next git commit command to create a merge commit. This
84 allows you to create a single commit on top of the current branch
85 whose effect is the same as merging another branch (or more in case
86 of an octopus).
87 With --no-squash perform the merge and commit the result. This
89 option can be used to override --squash.
90 --ff-only
92 Refuse to merge and exit with a non-zero status unless the current
93 HEAD is already up-to-date or the merge can be resolved as a
94 fast-forward.
95 -s <strategy>, --strategy=<strategy>
97 Use the given merge strategy; can be supplied more than once to
98 specify them in the order they should be tried. If there is no -s
99 option, a built-in list of strategies is used instead (git
100 merge-recursive when merging a single head, git merge-octopus
101 otherwise).
102 -X <option>, --strategy-option=<option>
104 Pass merge strategy specific option through to the merge strategy.
105 --summary, --no-summary
107 Synonyms to --stat and --no-stat; these are deprecated and will be
108 removed in the future.
109 -q, --quiet
111 Operate quietly.
112 -v, --verbose
114 Be verbose.
115 -m <msg>
117 Set the commit message to be used for the merge commit (in case one
118 is created). The git fmt-merge-msg command can be used to give a
119 good default for automated git merge invocations.
120 --rerere-autoupdate, --no-rerere-autoupdate
122 Allow the rerere mechanism to update the index with the result of
123 auto-conflict resolution if possible.
124 <commit>...
126 Commits, usually other branch heads, to merge into our branch. You
127 need at least one <commit>. Specifying more than one <commit>
128 obviously means you are trying an Octopus.
129
131 Before applying outside changes, you should get your own work in good
132 shape and committed locally, so it will not be clobbered if there are
133 conflicts. See also git-stash(1). git pull and git merge will stop
134 without doing anything when local uncommitted changes overlap with
135 files that git pull/git merge may need to update.
136 To avoid recording unrelated changes in the merge commit, git pull and
138 git merge will also abort if there are any changes registered in the
139 index relative to the HEAD commit. (One exception is when the changed
140 index entries are in the state that would result from the merge
141 already.)
142 If all named commits are already ancestors of HEAD, git merge will exit
144 early with the message "Already up-to-date."
145
147 Often the current branch head is an ancestor of the named commit. This
148 is the most common case especially when invoked from git pull: you are
149 tracking an upstream repository, you have committed no local changes,
150 and now you want to update to a newer upstream revision. In this case,
151 a new commit is not needed to store the combined history; instead, the
152 HEAD (along with the index) is updated to point at the named commit,
153 without creating an extra merge commit.
154 This behavior can be suppressed with the --no-ff option.
156
158 Except in a fast-forward merge (see above), the branches to be merged
159 must be tied together by a merge commit that has both of them as its
160 parents.
161 A merged version reconciling the changes from all branches to be merged
163 is committed, and your HEAD, index, and working tree are updated to it.
164 It is possible to have modifications in the working tree as long as
165 they do not overlap; the update will preserve them.
166 When it is not obvious how to reconcile the changes, the following
168 happens:
169 1. The HEAD pointer stays the same.
171 2. The MERGE_HEAD ref is set to point to the other branch head.
173 3. Paths that merged cleanly are updated both in the index file and in
175 your working tree.
176 4. For conflicting paths, the index file records up to three versions:
178 stage 1 stores the version from the common ancestor, stage 2 from
179 HEAD, and stage 3 from MERGE_HEAD (you can inspect the stages with
180 git ls-files -u). The working tree files contain the result of the
181 "merge" program; i.e. 3-way merge results with familiar conflict
182 markers <<< === >>>.
183 5. No other changes are made. In particular, the local modifications
185 you had before you started merge will stay the same and the index
186 entries for them stay as they were, i.e. matching HEAD.
187 If you tried a merge which resulted in complex conflicts and want to
189 start over, you can recover with git reset --merge.
190
192 During a merge, the working tree files are updated to reflect the
193 result of the merge. Among the changes made to the common ancestor’s
194 version, non-overlapping ones (that is, you changed an area of the file
195 while the other side left that area intact, or vice versa) are
196 incorporated in the final result verbatim. When both sides made changes
197 to the same area, however, git cannot randomly pick one side over the
198 other, and asks you to resolve it by leaving what both sides did to
199 that area.
200 By default, git uses the same style as that is used by "merge" program
202 from the RCS suite to present such a conflicted hunk, like this:
203 Here are lines that are either unchanged from the common
205 ancestor, or cleanly resolved because only one side changed.
206 <<<<<<< yours:sample.txt
207 Conflict resolution is hard;
208 let´s go shopping.
209 =======
210 Git makes conflict resolution easy.
211 >>>>>>> theirs:sample.txt
212 And here is another line that is cleanly resolved or unmodified.
213 The area where a pair of conflicting changes happened is marked with
216 markers <<<<<<<, =======, and >>>>>>>. The part before the ======= is
217 typically your side, and the part afterwards is typically their side.
218 The default format does not show what the original said in the
220 conflicting area. You cannot tell how many lines are deleted and
221 replaced with Barbie’s remark on your side. The only thing you can tell
222 is that your side wants to say it is hard and you’d prefer to go
223 shopping, while the other side wants to claim it is easy.
224 An alternative style can be used by setting the "merge.conflictstyle"
226 configuration variable to "diff3". In "diff3" style, the above conflict
227 may look like this:
228 Here are lines that are either unchanged from the common
230 ancestor, or cleanly resolved because only one side changed.
231 <<<<<<< yours:sample.txt
232 Conflict resolution is hard;
233 let´s go shopping.
234 |||||||
235 Conflict resolution is hard.
236 =======
237 Git makes conflict resolution easy.
238 >>>>>>> theirs:sample.txt
239 And here is another line that is cleanly resolved or unmodified.
240 In addition to the <<<<<<<, =======, and >>>>>>> markers, it uses
243 another ||||||| marker that is followed by the original text. You can
244 tell that the original just stated a fact, and your side simply gave in
245 to that statement and gave up, while the other side tried to have a
246 more positive attitude. You can sometimes come up with a better
247 resolution by viewing the original.
248
250 After seeing a conflict, you can do two things:
251 · Decide not to merge. The only clean-ups you need are to reset the
253 index file to the HEAD commit to reverse 2. and to clean up working
254 tree changes made by 2. and 3.; git-reset --hard can be used for
255 this.
256 · Resolve the conflicts. Git will mark the conflicts in the working
258 tree. Edit the files into shape and git add them to the index. Use
259 git commit to seal the deal.
260 You can work through the conflict with a number of tools:
262 · Use a mergetool. git mergetool to launch a graphical mergetool
264 which will work you through the merge.
265 · Look at the diffs. git diff will show a three-way diff,
267 highlighting changes from both the HEAD and MERGE_HEAD versions.
268 · Look at the diffs from each branch. git log --merge -p <path> will
270 show diffs first for the HEAD version and then the MERGE_HEAD
271 version.
272 · Look at the originals. git show :1:filename shows the common
274 ancestor, git show :2:filename shows the HEAD version, and git show
275 :3:filename shows the MERGE_HEAD version.
276
278 · Merge branches fixes and enhancements on top of the current branch,
279 making an octopus merge:
280 $ git merge fixes enhancements
282 · Merge branch obsolete into the current branch, using ours merge
285 strategy:
286 $ git merge -s ours obsolete
288 · Merge branch maint into the current branch, but do not make a new
291 commit automatically:
292 $ git merge --no-commit maint
294 This can be used when you want to include further changes to the
296 merge, or want to write your own merge commit message.
297 You should refrain from abusing this option to sneak substantial
299 changes into a merge commit. Small fixups like bumping
300 release/version name would be acceptable.
301
303 The merge mechanism (git-merge and git-pull commands) allows the
304 backend merge strategies to be chosen with -s option. Some strategies
305 can also take their own options, which can be passed by giving
306 -X<option> arguments to git-merge and/or git-pull.
307 resolve
309 This can only resolve two heads (i.e. the current branch and
310 another branch you pulled from) using a 3-way merge algorithm. It
311 tries to carefully detect criss-cross merge ambiguities and is
312 considered generally safe and fast.
313 recursive
315 This can only resolve two heads using a 3-way merge algorithm. When
316 there is more than one common ancestor that can be used for 3-way
317 merge, it creates a merged tree of the common ancestors and uses
318 that as the reference tree for the 3-way merge. This has been
319 reported to result in fewer merge conflicts without causing
320 mis-merges by tests done on actual merge commits taken from Linux
321 2.6 kernel development history. Additionally this can detect and
322 handle merges involving renames. This is the default merge strategy
323 when pulling or merging one branch.
324 The recursive strategy can take the following options:
326 ours
328 This option forces conflicting hunks to be auto-resolved
329 cleanly by favoring our version. Changes from the other tree
330 that do not conflict with our side are reflected to the merge
331 result.
332 This should not be confused with the ours merge strategy, which
334 does not even look at what the other tree contains at all. It
335 discards everything the other tree did, declaring our history
336 contains all that happened in it.
337 theirs
339 This is opposite of ours.
340 subtree[=path]
342 This option is a more advanced form of subtree strategy, where
343 the strategy makes a guess on how two trees must be shifted to
344 match with each other when merging. Instead, the specified path
345 is prefixed (or stripped from the beginning) to make the shape
346 of two trees to match.
347 octopus
349 This resolves cases with more than two heads, but refuses to do a
350 complex merge that needs manual resolution. It is primarily meant
351 to be used for bundling topic branch heads together. This is the
352 default merge strategy when pulling or merging more than one
353 branch.
354 ours
356 This resolves any number of heads, but the resulting tree of the
357 merge is always that of the current branch head, effectively
358 ignoring all changes from all other branches. It is meant to be
359 used to supersede old development history of side branches. Note
360 that this is different from the -Xours option to the recursive
361 merge strategy.
362 subtree
364 This is a modified recursive strategy. When merging trees A and B,
365 if B corresponds to a subtree of A, B is first adjusted to match
366 the tree structure of A, instead of reading the trees at the same
367 level. This adjustment is also done to the common ancestor tree.
368
370 merge.conflictstyle
371 Specify the style in which conflicted hunks are written out to
372 working tree files upon merge. The default is "merge", which shows
373 a <<<<<<< conflict marker, changes made by one side, a =======
374 marker, changes made by the other side, and then a >>>>>>> marker.
375 An alternate style, "diff3", adds a ||||||| marker and the original
376 text before the ======= marker.
377 merge.log
379 Whether to include summaries of merged commits in newly created
380 merge commit messages. False by default.
381 merge.renameLimit
383 The number of files to consider when performing rename detection
384 during a merge; if not specified, defaults to the value of
385 diff.renameLimit.
386 merge.stat
388 Whether to print the diffstat between ORIG_HEAD and the merge
389 result at the end of the merge. True by default.
390 merge.tool
392 Controls which merge resolution program is used by git-
393 mergetool(1). Valid built-in values are: "kdiff3", "tkdiff",
394 "meld", "xxdiff", "emerge", "vimdiff", "gvimdiff", "diffuse",
395 "ecmerge", "tortoisemerge", "p4merge", "araxis" and "opendiff". Any
396 other value is treated is custom merge tool and there must be a
397 corresponding mergetool.<tool>.cmd option.
398 merge.verbosity
400 Controls the amount of output shown by the recursive merge
401 strategy. Level 0 outputs nothing except a final error message if
402 conflicts were detected. Level 1 outputs only conflicts, 2 outputs
403 conflicts and file changes. Level 5 and above outputs debugging
404 information. The default is level 2. Can be overridden by the
405 GIT_MERGE_VERBOSITY environment variable.
406 merge.<driver>.name
408 Defines a human-readable name for a custom low-level merge driver.
409 See gitattributes(5) for details.
410 merge.<driver>.driver
412 Defines the command that implements a custom low-level merge
413 driver. See gitattributes(5) for details.
414 merge.<driver>.recursive
416 Names a low-level merge driver to be used when performing an
417 internal merge between common ancestors. See gitattributes(5) for
418 details.
419 branch.<name>.mergeoptions
421 Sets default options for merging into branch <name>. The syntax and
422 supported options are the same as those of git merge, but option
423 values containing whitespace characters are currently not
424 supported.
425
427 git-fmt-merge-msg(1), git-pull(1), gitattributes(5), git-reset(1), git-
428 diff(1), git-ls-files(1), git-add(1), git-rm(1), git-mergetool(1)
429
431 Written by Junio C Hamano <gitster@pobox.com[1]>
432
434 Documentation by Junio C Hamano and the git-list
435 <git@vger.kernel.org[2]>.
436
438 Part of the git(1) suite
439
441 1. gitster@pobox.com
442 mailto:gitster@pobox.com
443 2. git@vger.kernel.org
445 mailto:git@vger.kernel.org
446Git 1.7.1 08/16/2017 GIT-MERGE(1)