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] [--[no-]edit]
10 [--no-verify] [-s <strategy>] [-X <strategy-option>] [-S[<keyid>]]
11 [--[no-]allow-unrelated-histories]
12 [--[no-]rerere-autoupdate] [-m <msg>] [-F <file>]
13 [--into-name <branch>] [<commit>...]
14 git merge (--continue | --abort | --quit)
15
17 Incorporates changes from the named commits (since the time their
18 histories diverged from the current branch) into the current branch.
19 This command is used by git pull to incorporate changes from another
20 repository and can be used by hand to merge changes from one branch
21 into another.
22 Assume the following history exists and the current branch is "master":
24 A---B---C topic
26 /
27 D---E---F---G master
28 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. Before the operation, ORIG_HEAD is set to the
34 tip of the current branch (C).
35 A---B---C topic
37 / \
38 D---E---F---G---H master
39 The second syntax ("git merge --abort") can only be run after the merge
41 has resulted in conflicts. git merge --abort will abort the merge
42 process and try to reconstruct the pre-merge state. However, if there
43 were uncommitted changes when the merge started (and especially if
44 those changes were further modified after the merge was started), git
45 merge --abort will in some cases be unable to reconstruct the original
46 (pre-merge) changes. Therefore:
47 Warning: Running git merge with non-trivial uncommitted changes is
49 discouraged: while possible, it may leave you in a state that is hard
50 to back out of in the case of a conflict.
51 The third syntax ("git merge --continue") can only be run after the
53 merge has resulted in conflicts.
54
56 --commit, --no-commit
57 Perform the merge and commit the result. This option can be used to
58 override --no-commit.
59 With --no-commit perform the merge and stop just before creating a
61 merge commit, to give the user a chance to inspect and further
62 tweak the merge result before committing.
63 Note that fast-forward updates do not create a merge commit and
65 therefore there is no way to stop those merges with --no-commit.
66 Thus, if you want to ensure your branch is not changed or updated
67 by the merge command, use --no-ff with --no-commit.
68 --edit, -e, --no-edit
70 Invoke an editor before committing successful mechanical merge to
71 further edit the auto-generated merge message, so that the user can
72 explain and justify the merge. The --no-edit option can be used to
73 accept the auto-generated message (this is generally discouraged).
74 The --edit (or -e) option is still useful if you are giving a draft
75 message with the -m option from the command line and want to edit
76 it in the editor.
77 Older scripts may depend on the historical behaviour of not
79 allowing the user to edit the merge log message. They will see an
80 editor opened when they run git merge. To make it easier to adjust
81 such scripts to the updated behaviour, the environment variable
82 GIT_MERGE_AUTOEDIT can be set to no at the beginning of them.
83 --cleanup=<mode>
85 This option determines how the merge message will be cleaned up
86 before committing. See git-commit(1) for more details. In addition,
87 if the <mode> is given a value of scissors, scissors will be
88 appended to MERGE_MSG before being passed on to the commit
89 machinery in the case of a merge conflict.
90 --ff, --no-ff, --ff-only
92 Specifies how a merge is handled when the merged-in history is
93 already a descendant of the current history. --ff is the default
94 unless merging an annotated (and possibly signed) tag that is not
95 stored in its natural place in the refs/tags/ hierarchy, in which
96 case --no-ff is assumed.
97 With --ff, when possible resolve the merge as a fast-forward (only
99 update the branch pointer to match the merged branch; do not create
100 a merge commit). When not possible (when the merged-in history is
101 not a descendant of the current history), create a merge commit.
102 With --no-ff, create a merge commit in all cases, even when the
104 merge could instead be resolved as a fast-forward.
105 With --ff-only, resolve the merge as a fast-forward when possible.
107 When not possible, refuse to merge and exit with a non-zero status.
108 -S[<keyid>], --gpg-sign[=<keyid>], --no-gpg-sign
110 GPG-sign the resulting merge commit. The keyid argument is optional
111 and defaults to the committer identity; if specified, it must be
112 stuck to the option without a space. --no-gpg-sign is useful to
113 countermand both commit.gpgSign configuration variable, and earlier
114 --gpg-sign.
115 --log[=<n>], --no-log
117 In addition to branch names, populate the log message with one-line
118 descriptions from at most <n> actual commits that are being merged.
119 See also git-fmt-merge-msg(1).
120 With --no-log do not list one-line descriptions from the actual
122 commits being merged.
123 --signoff, --no-signoff
125 Add a Signed-off-by trailer by the committer at the end of the
126 commit log message. The meaning of a signoff depends on the project
127 to which you’re committing. For example, it may certify that the
128 committer has the rights to submit the work under the project’s
129 license or agrees to some contributor representation, such as a
130 Developer Certificate of Origin. (See
131 http://developercertificate.org for the one used by the Linux
132 kernel and Git projects.) Consult the documentation or leadership
133 of the project to which you’re contributing to understand how the
134 signoffs are used in that project.
135 The --no-signoff option can be used to countermand an earlier
137 --signoff option on the command line.
138 --stat, -n, --no-stat
140 Show a diffstat at the end of the merge. The diffstat is also
141 controlled by the configuration option merge.stat.
142 With -n or --no-stat do not show a diffstat at the end of the
144 merge.
145 --squash, --no-squash
147 Produce the working tree and index state as if a real merge
148 happened (except for the merge information), but do not actually
149 make a commit, move the HEAD, or record $GIT_DIR/MERGE_HEAD (to
150 cause the next git commit command to create a merge commit). This
151 allows you to create a single commit on top of the current branch
152 whose effect is the same as merging another branch (or more in case
153 of an octopus).
154 With --no-squash perform the merge and commit the result. This
156 option can be used to override --squash.
157 With --squash, --commit is not allowed, and will fail.
159 --[no-]verify
161 By default, the pre-merge and commit-msg hooks are run. When
162 --no-verify is given, these are bypassed. See also githooks(5).
163 -s <strategy>, --strategy=<strategy>
165 Use the given merge strategy; can be supplied more than once to
166 specify them in the order they should be tried. If there is no -s
167 option, a built-in list of strategies is used instead (ort when
168 merging a single head, octopus otherwise).
169 -X <option>, --strategy-option=<option>
171 Pass merge strategy specific option through to the merge strategy.
172 --verify-signatures, --no-verify-signatures
174 Verify that the tip commit of the side branch being merged is
175 signed with a valid key, i.e. a key that has a valid uid: in the
176 default trust model, this means the signing key has been signed by
177 a trusted key. If the tip commit of the side branch is not signed
178 with a valid key, the merge is aborted.
179 --summary, --no-summary
181 Synonyms to --stat and --no-stat; these are deprecated and will be
182 removed in the future.
183 -q, --quiet
185 Operate quietly. Implies --no-progress.
186 -v, --verbose
188 Be verbose.
189 --progress, --no-progress
191 Turn progress on/off explicitly. If neither is specified, progress
192 is shown if standard error is connected to a terminal. Note that
193 not all merge strategies may support progress reporting.
194 --autostash, --no-autostash
196 Automatically create a temporary stash entry before the operation
197 begins, record it in the special ref MERGE_AUTOSTASH and apply it
198 after the operation ends. This means that you can run the operation
199 on a dirty worktree. However, use with care: the final stash
200 application after a successful merge might result in non-trivial
201 conflicts.
202 --allow-unrelated-histories
204 By default, git merge command refuses to merge histories that do
205 not share a common ancestor. This option can be used to override
206 this safety when merging histories of two projects that started
207 their lives independently. As that is a very rare occasion, no
208 configuration variable to enable this by default exists and will
209 not be added.
210 -m <msg>
212 Set the commit message to be used for the merge commit (in case one
213 is created).
214 If --log is specified, a shortlog of the commits being merged will
216 be appended to the specified message.
217 The git fmt-merge-msg command can be used to give a good default
219 for automated git merge invocations. The automated message can
220 include the branch description.
221 --into-name <branch>
223 Prepare the default merge message as if merging to the branch
224 <branch>, instead of the name of the real branch to which the merge
225 is made.
226 -F <file>, --file=<file>
228 Read the commit message to be used for the merge commit (in case
229 one is created).
230 If --log is specified, a shortlog of the commits being merged will
232 be appended to the specified message.
233 --rerere-autoupdate, --no-rerere-autoupdate
235 After the rerere mechanism reuses a recorded resolution on the
236 current conflict to update the files in the working tree, allow it
237 to also update the index with the result of resolution.
238 --no-rerere-autoupdate is a good way to double-check what rerere
239 did and catch potential mismerges, before committing the result to
240 the index with a separate git add.
241 --overwrite-ignore, --no-overwrite-ignore
243 Silently overwrite ignored files from the merge result. This is the
244 default behavior. Use --no-overwrite-ignore to abort.
245 --abort
247 Abort the current conflict resolution process, and try to
248 reconstruct the pre-merge state. If an autostash entry is present,
249 apply it to the worktree.
250 If there were uncommitted worktree changes present when the merge
252 started, git merge --abort will in some cases be unable to
253 reconstruct these changes. It is therefore recommended to always
254 commit or stash your changes before running git merge.
255 git merge --abort is equivalent to git reset --merge when
257 MERGE_HEAD is present unless MERGE_AUTOSTASH is also present in
258 which case git merge --abort applies the stash entry to the
259 worktree whereas git reset --merge will save the stashed changes in
260 the stash list.
261 --quit
263 Forget about the current merge in progress. Leave the index and the
264 working tree as-is. If MERGE_AUTOSTASH is present, the stash entry
265 will be saved to the stash list.
266 --continue
268 After a git merge stops due to conflicts you can conclude the merge
269 by running git merge --continue (see "HOW TO RESOLVE CONFLICTS"
270 section below).
271 <commit>...
273 Commits, usually other branch heads, to merge into our branch.
274 Specifying more than one commit will create a merge with more than
275 two parents (affectionately called an Octopus merge).
276 If no commit is given from the command line, merge the
278 remote-tracking branches that the current branch is configured to
279 use as its upstream. See also the configuration section of this
280 manual page.
281 When FETCH_HEAD (and no other commit) is specified, the branches
283 recorded in the .git/FETCH_HEAD file by the previous invocation of
284 git fetch for merging are merged to the current branch.
285
287 Before applying outside changes, you should get your own work in good
288 shape and committed locally, so it will not be clobbered if there are
289 conflicts. See also git-stash(1). git pull and git merge will stop
290 without doing anything when local uncommitted changes overlap with
291 files that git pull/git merge may need to update.
292 To avoid recording unrelated changes in the merge commit, git pull and
294 git merge will also abort if there are any changes registered in the
295 index relative to the HEAD commit. (Special narrow exceptions to this
296 rule may exist depending on which merge strategy is in use, but
297 generally, the index must match HEAD.)
298 If all named commits are already ancestors of HEAD, git merge will exit
300 early with the message "Already up to date."
301
303 Often the current branch head is an ancestor of the named commit. This
304 is the most common case especially when invoked from git pull: you are
305 tracking an upstream repository, you have committed no local changes,
306 and now you want to update to a newer upstream revision. In this case,
307 a new commit is not needed to store the combined history; instead, the
308 HEAD (along with the index) is updated to point at the named commit,
309 without creating an extra merge commit.
310 This behavior can be suppressed with the --no-ff option.
312
314 Except in a fast-forward merge (see above), the branches to be merged
315 must be tied together by a merge commit that has both of them as its
316 parents.
317 A merged version reconciling the changes from all branches to be merged
319 is committed, and your HEAD, index, and working tree are updated to it.
320 It is possible to have modifications in the working tree as long as
321 they do not overlap; the update will preserve them.
322 When it is not obvious how to reconcile the changes, the following
324 happens:
325 1. The HEAD pointer stays the same.
327 2. The MERGE_HEAD ref is set to point to the other branch head.
329 3. Paths that merged cleanly are updated both in the index file and in
331 your working tree.
332 4. For conflicting paths, the index file records up to three versions:
334 stage 1 stores the version from the common ancestor, stage 2 from
335 HEAD, and stage 3 from MERGE_HEAD (you can inspect the stages with
336 git ls-files -u). The working tree files contain the result of the
337 merge operation; i.e. 3-way merge results with familiar conflict
338 markers <<< === >>>.
339 5. A special ref AUTO_MERGE is written, pointing to a tree
341 corresponding to the current content of the working tree (including
342 conflict markers for textual conflicts). Note that this ref is only
343 written when the ort merge strategy is used (the default).
344 6. No other changes are made. In particular, the local modifications
346 you had before you started merge will stay the same and the index
347 entries for them stay as they were, i.e. matching HEAD.
348 If you tried a merge which resulted in complex conflicts and want to
350 start over, you can recover with git merge --abort.
351
353 When merging an annotated (and possibly signed) tag, Git always creates
354 a merge commit even if a fast-forward merge is possible, and the commit
355 message template is prepared with the tag message. Additionally, if the
356 tag is signed, the signature check is reported as a comment in the
357 message template. See also git-tag(1).
358 When you want to just integrate with the work leading to the commit
360 that happens to be tagged, e.g. synchronizing with an upstream release
361 point, you may not want to make an unnecessary merge commit.
362 In such a case, you can "unwrap" the tag yourself before feeding it to
364 git merge, or pass --ff-only when you do not have any work on your own.
365 e.g.
366 git fetch origin
368 git merge v1.2.3^0
369 git merge --ff-only v1.2.3
370
372 During a merge, the working tree files are updated to reflect the
373 result of the merge. Among the changes made to the common ancestor’s
374 version, non-overlapping ones (that is, you changed an area of the file
375 while the other side left that area intact, or vice versa) are
376 incorporated in the final result verbatim. When both sides made changes
377 to the same area, however, Git cannot randomly pick one side over the
378 other, and asks you to resolve it by leaving what both sides did to
379 that area.
380 By default, Git uses the same style as the one used by the "merge"
382 program from the RCS suite to present such a conflicted hunk, like
383 this:
384 Here are lines that are either unchanged from the common
386 ancestor, or cleanly resolved because only one side changed,
387 or cleanly resolved because both sides changed the same way.
388 <<<<<<< yours:sample.txt
389 Conflict resolution is hard;
390 let's go shopping.
391 =======
392 Git makes conflict resolution easy.
393 >>>>>>> theirs:sample.txt
394 And here is another line that is cleanly resolved or unmodified.
395 The area where a pair of conflicting changes happened is marked with
397 markers <<<<<<<, =======, and >>>>>>>. The part before the ======= is
398 typically your side, and the part afterwards is typically their side.
399 The default format does not show what the original said in the
401 conflicting area. You cannot tell how many lines are deleted and
402 replaced with Barbie’s remark on your side. The only thing you can tell
403 is that your side wants to say it is hard and you’d prefer to go
404 shopping, while the other side wants to claim it is easy.
405 An alternative style can be used by setting the "merge.conflictStyle"
407 configuration variable to either "diff3" or "zdiff3". In "diff3" style,
408 the above conflict may look like this:
409 Here are lines that are either unchanged from the common
411 ancestor, or cleanly resolved because only one side changed,
412 <<<<<<< yours:sample.txt
413 or cleanly resolved because both sides changed the same way.
414 Conflict resolution is hard;
415 let's go shopping.
416 ||||||| base:sample.txt
417 or cleanly resolved because both sides changed identically.
418 Conflict resolution is hard.
419 =======
420 or cleanly resolved because both sides changed the same way.
421 Git makes conflict resolution easy.
422 >>>>>>> theirs:sample.txt
423 And here is another line that is cleanly resolved or unmodified.
424 while in "zdiff3" style, it may look like this:
426 Here are lines that are either unchanged from the common
428 ancestor, or cleanly resolved because only one side changed,
429 or cleanly resolved because both sides changed the same way.
430 <<<<<<< yours:sample.txt
431 Conflict resolution is hard;
432 let's go shopping.
433 ||||||| base:sample.txt
434 or cleanly resolved because both sides changed identically.
435 Conflict resolution is hard.
436 =======
437 Git makes conflict resolution easy.
438 >>>>>>> theirs:sample.txt
439 And here is another line that is cleanly resolved or unmodified.
440 In addition to the <<<<<<<, =======, and >>>>>>> markers, it uses
442 another ||||||| marker that is followed by the original text. You can
443 tell that the original just stated a fact, and your side simply gave in
444 to that statement and gave up, while the other side tried to have a
445 more positive attitude. You can sometimes come up with a better
446 resolution by viewing the original.
447
449 After seeing a conflict, you can do two things:
450 • Decide not to merge. The only clean-ups you need are to reset the
452 index file to the HEAD commit to reverse 2. and to clean up working
453 tree changes made by 2. and 3.; git merge --abort can be used for
454 this.
455 • Resolve the conflicts. Git will mark the conflicts in the working
457 tree. Edit the files into shape and git add them to the index. Use
458 git commit or git merge --continue to seal the deal. The latter
459 command checks whether there is a (interrupted) merge in progress
460 before calling git commit.
461 You can work through the conflict with a number of tools:
463 • Use a mergetool. git mergetool to launch a graphical mergetool
465 which will work through the merge with you.
466 • Look at the diffs. git diff will show a three-way diff,
468 highlighting changes from both the HEAD and MERGE_HEAD versions.
469 git diff AUTO_MERGE will show what changes you’ve made so far to
470 resolve textual conflicts.
471 • Look at the diffs from each branch. git log --merge -p <path> will
473 show diffs first for the HEAD version and then the MERGE_HEAD
474 version.
475 • Look at the originals. git show :1:filename shows the common
477 ancestor, git show :2:filename shows the HEAD version, and git show
478 :3:filename shows the MERGE_HEAD version.
479
481 • Merge branches fixes and enhancements on top of the current branch,
482 making an octopus merge:
483 $ git merge fixes enhancements
485 • Merge branch obsolete into the current branch, using ours merge
487 strategy:
488 $ git merge -s ours obsolete
490 • Merge branch maint into the current branch, but do not make a new
492 commit automatically:
493 $ git merge --no-commit maint
495 This can be used when you want to include further changes to the
497 merge, or want to write your own merge commit message.
498 You should refrain from abusing this option to sneak substantial
500 changes into a merge commit. Small fixups like bumping
501 release/version name would be acceptable.
502
504 The merge mechanism (git merge and git pull commands) allows the
505 backend merge strategies to be chosen with -s option. Some strategies
506 can also take their own options, which can be passed by giving
507 -X<option> arguments to git merge and/or git pull.
508 ort
510 This is the default merge strategy when pulling or merging one
511 branch. This strategy can only resolve two heads using a 3-way
512 merge algorithm. When there is more than one common ancestor that
513 can be used for 3-way merge, it creates a merged tree of the common
514 ancestors and uses that as the reference tree for the 3-way merge.
515 This has been reported to result in fewer merge conflicts without
516 causing mismerges by tests done on actual merge commits taken from
517 Linux 2.6 kernel development history. Additionally this strategy
518 can detect and handle merges involving renames. It does not make
519 use of detected copies. The name for this algorithm is an acronym
520 ("Ostensibly Recursive’s Twin") and came from the fact that it was
521 written as a replacement for the previous default algorithm,
522 recursive.
523 The ort strategy can take the following options:
525 ours
527 This option forces conflicting hunks to be auto-resolved
528 cleanly by favoring our version. Changes from the other tree
529 that do not conflict with our side are reflected in the merge
530 result. For a binary file, the entire contents are taken from
531 our side.
532 This should not be confused with the ours merge strategy, which
534 does not even look at what the other tree contains at all. It
535 discards everything the other tree did, declaring our history
536 contains all that happened in it.
537 theirs
539 This is the opposite of ours; note that, unlike ours, there is
540 no theirs merge strategy to confuse this merge option with.
541 ignore-space-change, ignore-all-space, ignore-space-at-eol,
543 ignore-cr-at-eol
544 Treats lines with the indicated type of whitespace change as
545 unchanged for the sake of a three-way merge. Whitespace changes
546 mixed with other changes to a line are not ignored. See also
547 git-diff(1) -b, -w, --ignore-space-at-eol, and
548 --ignore-cr-at-eol.
549 • If their version only introduces whitespace changes to a
551 line, our version is used;
552 • If our version introduces whitespace changes but their
554 version includes a substantial change, their version is
555 used;
556 • Otherwise, the merge proceeds in the usual way.
558 renormalize
560 This runs a virtual check-out and check-in of all three stages
561 of a file when resolving a three-way merge. This option is
562 meant to be used when merging branches with different clean
563 filters or end-of-line normalization rules. See "Merging
564 branches with differing checkin/checkout attributes" in
565 gitattributes(5) for details.
566 no-renormalize
568 Disables the renormalize option. This overrides the
569 merge.renormalize configuration variable.
570 find-renames[=<n>]
572 Turn on rename detection, optionally setting the similarity
573 threshold. This is the default. This overrides the
574 merge.renames configuration variable. See also git-diff(1)
575 --find-renames.
576 rename-threshold=<n>
578 Deprecated synonym for find-renames=<n>.
579 subtree[=<path>]
581 This option is a more advanced form of subtree strategy, where
582 the strategy makes a guess on how two trees must be shifted to
583 match with each other when merging. Instead, the specified path
584 is prefixed (or stripped from the beginning) to make the shape
585 of two trees to match.
586 recursive
588 This can only resolve two heads using a 3-way merge algorithm. When
589 there is more than one common ancestor that can be used for 3-way
590 merge, it creates a merged tree of the common ancestors and uses
591 that as the reference tree for the 3-way merge. This has been
592 reported to result in fewer merge conflicts without causing
593 mismerges by tests done on actual merge commits taken from Linux
594 2.6 kernel development history. Additionally this can detect and
595 handle merges involving renames. It does not make use of detected
596 copies. This was the default strategy for resolving two heads from
597 Git v0.99.9k until v2.33.0.
598 The recursive strategy takes the same options as ort. However,
600 there are three additional options that ort ignores (not documented
601 above) that are potentially useful with the recursive strategy:
602 patience
604 Deprecated synonym for diff-algorithm=patience.
605 diff-algorithm=[patience|minimal|histogram|myers]
607 Use a different diff algorithm while merging, which can help
608 avoid mismerges that occur due to unimportant matching lines
609 (such as braces from distinct functions). See also git-diff(1)
610 --diff-algorithm. Note that ort specifically uses
611 diff-algorithm=histogram, while recursive defaults to the
612 diff.algorithm config setting.
613 no-renames
615 Turn off rename detection. This overrides the merge.renames
616 configuration variable. See also git-diff(1) --no-renames.
617 resolve
619 This can only resolve two heads (i.e. the current branch and
620 another branch you pulled from) using a 3-way merge algorithm. It
621 tries to carefully detect criss-cross merge ambiguities. It does
622 not handle renames.
623 octopus
625 This resolves cases with more than two heads, but refuses to do a
626 complex merge that needs manual resolution. It is primarily meant
627 to be used for bundling topic branch heads together. This is the
628 default merge strategy when pulling or merging more than one
629 branch.
630 ours
632 This resolves any number of heads, but the resulting tree of the
633 merge is always that of the current branch head, effectively
634 ignoring all changes from all other branches. It is meant to be
635 used to supersede old development history of side branches. Note
636 that this is different from the -Xours option to the recursive
637 merge strategy.
638 subtree
640 This is a modified ort strategy. When merging trees A and B, if B
641 corresponds to a subtree of A, B is first adjusted to match the
642 tree structure of A, instead of reading the trees at the same
643 level. This adjustment is also done to the common ancestor tree.
644 With the strategies that use 3-way merge (including the default, ort),
646 if a change is made on both branches, but later reverted on one of the
647 branches, that change will be present in the merged result; some people
648 find this behavior confusing. It occurs because only the heads and the
649 merge base are considered when performing a merge, not the individual
650 commits. The merge algorithm therefore considers the reverted change as
651 no change at all, and substitutes the changed version instead.
652
654 branch.<name>.mergeOptions
655 Sets default options for merging into branch <name>. The syntax and
656 supported options are the same as those of git merge, but option
657 values containing whitespace characters are currently not
658 supported.
659 Everything above this line in this section isn’t included from the git-
661 config(1) documentation. The content that follows is the same as what’s
662 found there:
663 merge.conflictStyle
665 Specify the style in which conflicted hunks are written out to
666 working tree files upon merge. The default is "merge", which shows
667 a <<<<<<< conflict marker, changes made by one side, a =======
668 marker, changes made by the other side, and then a >>>>>>> marker.
669 An alternate style, "diff3", adds a ||||||| marker and the original
670 text before the ======= marker. The "merge" style tends to produce
671 smaller conflict regions than diff3, both because of the exclusion
672 of the original text, and because when a subset of lines match on
673 the two sides, they are just pulled out of the conflict region.
674 Another alternate style, "zdiff3", is similar to diff3 but removes
675 matching lines on the two sides from the conflict region when those
676 matching lines appear near either the beginning or end of a
677 conflict region.
678 merge.defaultToUpstream
680 If merge is called without any commit argument, merge the upstream
681 branches configured for the current branch by using their last
682 observed values stored in their remote-tracking branches. The
683 values of the branch.<current branch>.merge that name the branches
684 at the remote named by branch.<current branch>.remote are
685 consulted, and then they are mapped via remote.<remote>.fetch to
686 their corresponding remote-tracking branches, and the tips of these
687 tracking branches are merged. Defaults to true.
688 merge.ff
690 By default, Git does not create an extra merge commit when merging
691 a commit that is a descendant of the current commit. Instead, the
692 tip of the current branch is fast-forwarded. When set to false,
693 this variable tells Git to create an extra merge commit in such a
694 case (equivalent to giving the --no-ff option from the command
695 line). When set to only, only such fast-forward merges are allowed
696 (equivalent to giving the --ff-only option from the command line).
697 merge.verifySignatures
699 If true, this is equivalent to the --verify-signatures command line
700 option. See git-merge(1) for details.
701 merge.branchdesc
703 In addition to branch names, populate the log message with the
704 branch description text associated with them. Defaults to false.
705 merge.log
707 In addition to branch names, populate the log message with at most
708 the specified number of one-line descriptions from the actual
709 commits that are being merged. Defaults to false, and true is a
710 synonym for 20.
711 merge.suppressDest
713 By adding a glob that matches the names of integration branches to
714 this multi-valued configuration variable, the default merge message
715 computed for merges into these integration branches will omit "into
716 <branch name>" from its title.
717 An element with an empty value can be used to clear the list of
719 globs accumulated from previous configuration entries. When there
720 is no merge.suppressDest variable defined, the default value of
721 master is used for backward compatibility.
722 merge.renameLimit
724 The number of files to consider in the exhaustive portion of rename
725 detection during a merge. If not specified, defaults to the value
726 of diff.renameLimit. If neither merge.renameLimit nor
727 diff.renameLimit are specified, currently defaults to 7000. This
728 setting has no effect if rename detection is turned off.
729 merge.renames
731 Whether Git detects renames. If set to "false", rename detection is
732 disabled. If set to "true", basic rename detection is enabled.
733 Defaults to the value of diff.renames.
734 merge.directoryRenames
736 Whether Git detects directory renames, affecting what happens at
737 merge time to new files added to a directory on one side of history
738 when that directory was renamed on the other side of history. If
739 merge.directoryRenames is set to "false", directory rename
740 detection is disabled, meaning that such new files will be left
741 behind in the old directory. If set to "true", directory rename
742 detection is enabled, meaning that such new files will be moved
743 into the new directory. If set to "conflict", a conflict will be
744 reported for such paths. If merge.renames is false,
745 merge.directoryRenames is ignored and treated as false. Defaults to
746 "conflict".
747 merge.renormalize
749 Tell Git that canonical representation of files in the repository
750 has changed over time (e.g. earlier commits record text files with
751 CRLF line endings, but recent ones use LF line endings). In such a
752 repository, Git can convert the data recorded in commits to a
753 canonical form before performing a merge to reduce unnecessary
754 conflicts. For more information, see section "Merging branches with
755 differing checkin/checkout attributes" in gitattributes(5).
756 merge.stat
758 Whether to print the diffstat between ORIG_HEAD and the merge
759 result at the end of the merge. True by default.
760 merge.autoStash
762 When set to true, automatically create a temporary stash entry
763 before the operation begins, and apply it after the operation ends.
764 This means that you can run merge on a dirty worktree. However, use
765 with care: the final stash application after a successful merge
766 might result in non-trivial conflicts. This option can be
767 overridden by the --no-autostash and --autostash options of git-
768 merge(1). Defaults to false.
769 merge.tool
771 Controls which merge tool is used by git-mergetool(1). The list
772 below shows the valid built-in values. Any other value is treated
773 as a custom merge tool and requires that a corresponding
774 mergetool.<tool>.cmd variable is defined.
775 merge.guitool
777 Controls which merge tool is used by git-mergetool(1) when the
778 -g/--gui flag is specified. The list below shows the valid built-in
779 values. Any other value is treated as a custom merge tool and
780 requires that a corresponding mergetool.<guitool>.cmd variable is
781 defined.
782 araxis
784 Use Araxis Merge (requires a graphical session)
785 bc
787 Use Beyond Compare (requires a graphical session)
788 bc3
790 Use Beyond Compare (requires a graphical session)
791 bc4
793 Use Beyond Compare (requires a graphical session)
794 codecompare
796 Use Code Compare (requires a graphical session)
797 deltawalker
799 Use DeltaWalker (requires a graphical session)
800 diffmerge
802 Use DiffMerge (requires a graphical session)
803 diffuse
805 Use Diffuse (requires a graphical session)
806 ecmerge
808 Use ECMerge (requires a graphical session)
809 emerge
811 Use Emacs' Emerge
812 examdiff
814 Use ExamDiff Pro (requires a graphical session)
815 guiffy
817 Use Guiffy’s Diff Tool (requires a graphical session)
818 gvimdiff
820 Use gVim (requires a graphical session) with a custom layout
821 (see git help mergetool's BACKEND SPECIFIC HINTS section)
822 gvimdiff1
824 Use gVim (requires a graphical session) with a 2 panes layout
825 (LOCAL and REMOTE)
826 gvimdiff2
828 Use gVim (requires a graphical session) with a 3 panes layout
829 (LOCAL, MERGED and REMOTE)
830 gvimdiff3
832 Use gVim (requires a graphical session) where only the MERGED
833 file is shown
834 kdiff3
836 Use KDiff3 (requires a graphical session)
837 meld
839 Use Meld (requires a graphical session) with optional auto
840 merge (see git help mergetool's CONFIGURATION section)
841 nvimdiff
843 Use Neovim with a custom layout (see git help mergetool's
844 BACKEND SPECIFIC HINTS section)
845 nvimdiff1
847 Use Neovim with a 2 panes layout (LOCAL and REMOTE)
848 nvimdiff2
850 Use Neovim with a 3 panes layout (LOCAL, MERGED and REMOTE)
851 nvimdiff3
853 Use Neovim where only the MERGED file is shown
854 opendiff
856 Use FileMerge (requires a graphical session)
857 p4merge
859 Use HelixCore P4Merge (requires a graphical session)
860 smerge
862 Use Sublime Merge (requires a graphical session)
863 tkdiff
865 Use TkDiff (requires a graphical session)
866 tortoisemerge
868 Use TortoiseMerge (requires a graphical session)
869 vimdiff
871 Use Vim with a custom layout (see git help mergetool's BACKEND
872 SPECIFIC HINTS section)
873 vimdiff1
875 Use Vim with a 2 panes layout (LOCAL and REMOTE)
876 vimdiff2
878 Use Vim with a 3 panes layout (LOCAL, MERGED and REMOTE)
879 vimdiff3
881 Use Vim where only the MERGED file is shown
882 winmerge
884 Use WinMerge (requires a graphical session)
885 xxdiff
887 Use xxdiff (requires a graphical session)
888 merge.verbosity
890 Controls the amount of output shown by the recursive merge
891 strategy. Level 0 outputs nothing except a final error message if
892 conflicts were detected. Level 1 outputs only conflicts, 2 outputs
893 conflicts and file changes. Level 5 and above outputs debugging
894 information. The default is level 2. Can be overridden by the
895 GIT_MERGE_VERBOSITY environment variable.
896 merge.<driver>.name
898 Defines a human-readable name for a custom low-level merge driver.
899 See gitattributes(5) for details.
900 merge.<driver>.driver
902 Defines the command that implements a custom low-level merge
903 driver. See gitattributes(5) for details.
904 merge.<driver>.recursive
906 Names a low-level merge driver to be used when performing an
907 internal merge between common ancestors. See gitattributes(5) for
908 details.
909
911 git-fmt-merge-msg(1), git-pull(1), gitattributes(5), git-reset(1), git-
912 diff(1), git-ls-files(1), git-add(1), git-rm(1), git-mergetool(1)
913
915 Part of the git(1) suite
916Git 2.43.0 11/20/2023 GIT-MERGE(1)