Git

git-merge 上次更新于 2.50.0

名称

git-merge - 合并两个或多个开发历史

概要

git merge [-n] [--stat] [--no-commit] [--squash] [--[no-]edit]
	[--no-verify] [-s <strategy>] [-X <strategy-option>] [-S[<keyid>]]
	[--[no-]allow-unrelated-histories]
	[--[no-]rerere-autoupdate] [-m <msg>] [-F <file>]
	[--into-name <branch>] [<commit>…]
git merge (--continue | --abort | --quit)

描述

将指定提交中的更改（自其历史与当前分支分离以来）整合到当前分支中。此命令由 git pull 用于整合来自其他仓库的更改，也可以手动用于将一个分支的更改合并到另一个分支中。

假设存在以下历史，并且当前分支是 master

	  A---B---C topic
	 /
    D---E---F---G master

然后 git merge topic 将重播 topic 分支自其与 master 分离（即 E）到其当前提交 (C) 之间所做的更改，并将其记录在 master 之上的一个新提交中，同时包含两个父提交的名称和用户描述更改的日志消息。在操作之前，ORIG_HEAD 被设置为当前分支的尖端 (C)。

	  A---B---C topic
	 /         \
    D---E---F---G---H master

如果存在无法自动解决的冲突，或者在启动合并时提供了 --no-commit，则合并会停止。此时，您可以运行 git merge --abort 或 git merge --continue。

git merge --abort 将中止合并过程并尝试重建合并前的状态。但是，如果合并开始时存在未提交的更改（尤其是如果这些更改在合并开始后进一步修改），git merge --abort 在某些情况下将无法重建原始（合并前）更改。因此

警告	不建议在存在非平凡的未提交更改时运行 `git` `merge`：虽然可能，但在发生冲突时，它可能会使您处于难以退出的状态。

选项

--commit
--no-commit: 执行合并并提交结果。此选项可用于覆盖 --no-commit。

使用 --no-commit 执行合并，并在创建合并提交之前停止，以便用户有机会在提交之前检查和进一步调整合并结果。

请注意，快进式更新不会创建合并提交，因此无法使用 --no-commit 停止这些合并。因此，如果您想确保您的分支不会因合并命令而更改或更新，请将 --no-ff 与 --no-commit 一起使用。
--edit
-e
--no-edit: 在提交成功的机械合并之前调用编辑器，以进一步编辑自动生成的合并消息，以便用户可以解释和说明合并。可以使用 --no-edit 选项接受自动生成的消息（通常不建议这样做）。如果您通过命令行使用 -m 选项提供草稿消息并希望在编辑器中对其进行编辑，则 --edit (或 -e) 选项仍然有用。

较旧的脚本可能依赖于不允许用户编辑合并日志消息的历史行为。当它们运行 git merge 时，它们将看到一个编辑器打开。为了更容易地调整此类脚本以适应更新的行为，可以在脚本开头将环境变量 GIT_MERGE_AUTOEDIT 设置为 no。
--cleanup=<mode>: 此选项决定了在提交之前如何清理合并消息。有关更多详细信息，请参阅 git-commit[1]。此外，如果 <mode> 被赋予 scissors 值，则在发生合并冲突时，剪刀将附加到 MERGE_MSG，然后再传递给提交机制。
--ff
--no-ff
--ff-only: 指定当被合并的历史已经是当前历史的后代时，如何处理合并。--ff 是默认设置，除非合并的是未存储在其在 refs/tags/ 层级结构中的自然位置的带注释（可能已签名）标签，在这种情况下，假定为 --no-ff。

使用 --ff，如果可能，将合并解析为快进（仅更新分支指针以匹配合并的分支；不创建合并提交）。如果不可能（当被合并的历史不是当前历史的后代时），则创建合并提交。

使用 --no-ff，在所有情况下都创建合并提交，即使合并可以解析为快进。

使用 --ff-only，如果可能，将合并解析为快进。如果不可能，则拒绝合并并以非零状态退出。
-S[<key-id>]
--gpg-sign[=<key-id>]
--no-gpg-sign: 对生成的合并提交进行 GPG 签名。<key-id> 参数是可选的，默认为提交者身份；如果指定，它必须紧贴选项，中间不能有空格。--no-gpg-sign 对于抵消 commit.gpgSign 配置变量和先前的 --gpg-sign 都很有用。
--log[=<n>]
--no-log: 除了分支名称之外，还用最多 <n> 个实际被合并的提交的单行描述填充日志消息。另请参阅 git-fmt-merge-msg[1]。

使用 --no-log 不列出实际被合并的提交的单行描述。
--signoff
--no-signoff: 在提交日志消息末尾添加提交者的 Signed-off-by 尾部信息。签名的含义取决于您提交的项目。例如，它可能证明提交者有权根据项目的许可证提交作品，或者同意某些贡献者声明，例如开发者原产地证书。（有关 Linux 内核和 Git 项目使用的证书，请参阅 https://developercertificate.org。）请查阅您所贡献项目的文档或领导层，以了解该项目中签名的使用方式。

可以使用 --no-signoff 选项来抵消命令行中较早的 --signoff 选项。
--stat
-n
--no-stat: 在合并结束时显示 diffstat。diffstat 也受配置选项 merge.stat 控制。

使用 -n 或 --no-stat 不在合并结束时显示 diffstat。
--squash
--no-squash: 生成工作树和索引状态，就像实际合并发生一样（合并信息除外），但实际上不进行提交，不移动 HEAD，也不记录 $GIT_DIR/MERGE_HEAD（以使下一个 git commit 命令创建合并提交）。这允许您在当前分支之上创建一个单独的提交，其效果与合并另一个分支（或在章鱼合并的情况下更多）相同。

使用 --no-squash 执行合并并提交结果。此选项可用于覆盖 --squash。

使用 --squash 时，不允许使用 --commit，并且会失败。
--[no-]verify: 默认情况下，pre-merge 和 commit-msg 钩子会被运行。当给出 --no-verify 时，这些钩子会被绕过。另请参阅 githooks[5]。
-s <strategy>
--strategy=<strategy>: 使用给定的合并策略；可以多次提供以指定它们的尝试顺序。如果没有 -s 选项，则使用内置策略列表（合并单个头时使用 ort，否则使用 octopus）。
-X <option>
--strategy-option=<option>: 将合并策略特定选项传递给合并策略。
--verify-signatures
--no-verify-signatures: 验证被合并的侧分支的尖端提交是否用有效密钥签名，即在默认信任模型中，这意味着签名密钥已由受信任密钥签名。如果侧分支的尖端提交未用有效密钥签名，则合并中止。
--summary
--no-summary: 等同于 --stat 和 --no-stat；这些已被弃用，将来会移除。
-q
--quiet: 安静操作。隐含 --no-progress。
-v
--verbose: 显示详细信息。
--progress
--no-progress: 显式开启/关闭进度显示。如果两者都未指定，则当标准错误连接到终端时显示进度。请注意，并非所有合并策略都可能支持进度报告。
--autostash
--no-autostash: 在操作开始前自动创建一个临时暂存条目，将其记录在引用 MERGE_AUTOSTASH 中，并在操作结束后应用。这意味着您可以在脏工作树上运行操作。但是，请谨慎使用：成功合并后的最终暂存应用可能会导致非平凡的冲突。
--allow-unrelated-histories: 默认情况下，git merge 命令拒绝合并没有共同祖先的历史。此选项可用于在合并两个独立开始的项目历史时覆盖此安全限制。由于这种情况非常罕见，因此不存在或不会添加默认启用此功能的配置变量。
-m <msg>: 设置合并提交（如果创建）要使用的提交消息。

如果指定了 --log，则合并的提交的简短日志将附加到指定的消息中。

命令 git fmt-merge-msg 可用于为自动 git merge 调用提供一个良好的默认值。自动生成的消息可以包含分支描述。
--into-name <branch>: 准备默认合并消息，就像合并到分支 <branch> 一样，而不是合并到的实际分支的名称。
-F <file>
--file=<file>: 读取合并提交（如果创建）要使用的提交消息。

如果指定了 --log，则合并的提交的简短日志将附加到指定的消息中。
--rerere-autoupdate
--no-rerere-autoupdate: 在 rerere 机制重用当前冲突上的已记录解决方案来更新工作树中的文件之后，允许它也用解决方案结果更新索引。--no-rerere-autoupdate 是一个很好的方式来仔细检查 rerere 的作用，并在使用单独的 git add 将结果提交到索引之前捕获潜在的错误合并。
--overwrite-ignore
--no-overwrite-ignore: 静默覆盖合并结果中的忽略文件。这是默认行为。使用 --no-overwrite-ignore 来中止。
--abort: 中止当前的冲突解决过程，并尝试重建合并前的状态。如果存在自动暂存条目，则将其应用于工作树。

如果合并开始时存在未提交的工作树更改，git merge --abort 在某些情况下将无法重建这些更改。因此，建议在运行 git merge 之前始终提交或暂存您的更改。

当 MERGE_HEAD 存在时，git merge --abort 等同于 git reset --merge，除非 MERGE_AUTOSTASH 也存在，在这种情况下，git merge --abort 将暂存条目应用于工作树，而 git reset --merge 将保存暂存的更改到暂存列表中。
--quit: 忘记当前正在进行的合并。保持索引和工作树原样。如果 MERGE_AUTOSTASH 存在，则暂存条目将保存到暂存列表中。
--continue: 在 git merge 因冲突停止后，您可以运行 git merge --continue 来完成合并（请参阅下面的“如何解决冲突”部分）。
<commit>...: 提交，通常是其他分支的头，合并到我们的分支。指定多个提交将创建一个具有两个以上父级的合并（亲切地称为章鱼合并）。

如果命令行中没有给出任何提交，则合并当前分支配置为用作其上游的远程跟踪分支。另请参阅本手册页的配置部分。

当指定 FETCH_HEAD（且没有其他提交）时，.git/FETCH_HEAD 文件中由上一次 git fetch 调用为合并而记录的分支将被合并到当前分支。

合并前检查

在应用外部更改之前，您应该确保自己的工作状态良好并已在本地提交，这样在发生冲突时就不会被覆盖。另请参阅 git-stash[1]。git pull 和 git merge 在本地未提交的更改与 git pull/git merge 可能需要更新的文件重叠时，将停止而不做任何操作。

为了避免在合并提交中记录不相关的更改，如果索引中相对于 HEAD 提交有任何更改，git pull 和 git merge 也将中止。（根据所使用的合并策略，此规则可能存在特殊的窄例外，但通常，索引必须与 HEAD 匹配。）

如果所有命名提交都是 HEAD 的祖先，git merge 将提前退出并显示消息 "Already up to date."。

快进合并

通常，当前分支头是指定提交的祖先。这在从 git pull 调用时最常见：您正在跟踪上游仓库，您没有提交任何本地更改，现在您想更新到较新的上游修订版本。在这种情况下，不需要新的提交来存储组合历史；相反，HEAD（以及索引）会更新以指向指定的提交，而不创建额外的合并提交。

此行为可以使用 --no-ff 选项来抑制。

真实合并

除了快进合并（见上文）之外，要合并的分支必须通过一个合并提交连接起来，该提交将它们两者都作为其父级。

将所有要合并的分支的更改进行协调的版本被提交，并且您的 HEAD、索引和工作树会更新到该版本。只要工作树中的修改不重叠，就可以保留它们；更新将保留它们。

当如何协调更改不明显时，会发生以下情况

HEAD 指针保持不变。
MERGE_HEAD 引用被设置为指向另一个分支头。
干净合并的路径在索引文件和工作树中都得到了更新。
对于冲突路径，索引文件最多记录三个版本：阶段 1 存储来自共同祖先的版本，阶段 2 存储来自 HEAD 的版本，阶段 3 存储来自 MERGE_HEAD 的版本（您可以使用 git ls-files -u 检查这些阶段）。工作树文件包含合并操作的结果；即带有常见冲突标记 <<< === >>> 的三方合并结果。
写入一个名为 AUTO_MERGE 的引用，指向一个与工作树当前内容（包括文本冲突的冲突标记）对应的树。请注意，此引用仅在使用 ort 合并策略（默认）时写入。
没有进行其他更改。特别是，您在开始合并之前所做的本地修改将保持不变，并且它们的索引条目也保持原样，即与 HEAD 匹配。

如果您尝试了一次导致复杂冲突的合并，并且想重新开始，您可以使用 git merge --abort 进行恢复。

合并标签

当合并一个带注释（可能已签名）的标签时，即使可以进行快进合并，Git 也总是会创建一个合并提交，并且提交消息模板会使用标签消息进行准备。此外，如果标签已签名，签名检查会作为注释报告在消息模板中。另请参阅 git-tag[1]。

当您只想与导致提交的工作（恰好被标记）集成时，例如与上游发布点同步，您可能不想创建不必要的合并提交。

在这种情况下，您可以在将其提供给 git merge 之前自行“解包”标签，或者在您没有任何自己的工作时传递 --ff-only。例如

git fetch origin
git merge v1.2.3^0
git merge --ff-only v1.2.3

冲突如何呈现

在合并过程中，工作树文件会更新以反映合并结果。在对共同祖先版本所做的更改中，不重叠的更改（即，您更改了文件的一个区域，而另一方保持该区域不变，反之亦然）将逐字纳入最终结果。但是，当双方都对同一区域进行了更改时，Git 无法随意选择一方，并要求您通过保留双方在该区域所做的内容来解决冲突。

默认情况下，Git 使用与 RCS 套件中的“merge”程序相同的样式来呈现此类冲突的块，如下所示

Here are lines that are either unchanged from the common
ancestor, or cleanly resolved because only one side changed,
or cleanly resolved because both sides changed the same way.
<<<<<<< yours:sample.txt
Conflict resolution is hard;
let's go shopping.
=======
Git makes conflict resolution easy.
>>>>>>> theirs:sample.txt
And here is another line that is cleanly resolved or unmodified.

发生一对冲突更改的区域用标记 <<<<<<<、======= 和 >>>>>>> 标记。 ======= 之前的部分通常是您这边的内容，之后的部分通常是对方这边的内容。

默认格式不显示原始冲突区域说了什么。您无法判断您的版本中删除了多少行并替换为芭比的评论。您唯一能知道的是，您这边想说这很困难，您更喜欢去购物，而另一边想声称这很容易。

可以通过将 merge.conflictStyle 配置变量设置为 diff3 或 zdiff3 来使用另一种样式。在 diff3 样式中，上述冲突可能看起来像这样

Here are lines that are either unchanged from the common
ancestor, or cleanly resolved because only one side changed,
<<<<<<< yours:sample.txt
or cleanly resolved because both sides changed the same way.
Conflict resolution is hard;
let's go shopping.
||||||| base:sample.txt
or cleanly resolved because both sides changed identically.
Conflict resolution is hard.
=======
or cleanly resolved because both sides changed the same way.
Git makes conflict resolution easy.
>>>>>>> theirs:sample.txt
And here is another line that is cleanly resolved or unmodified.

而在 zdiff3 样式中，它可能看起来像这样

Here are lines that are either unchanged from the common
ancestor, or cleanly resolved because only one side changed,
or cleanly resolved because both sides changed the same way.
<<<<<<< yours:sample.txt
Conflict resolution is hard;
let's go shopping.
||||||| base:sample.txt
or cleanly resolved because both sides changed identically.
Conflict resolution is hard.
=======
Git makes conflict resolution easy.
>>>>>>> theirs:sample.txt
And here is another line that is cleanly resolved or unmodified.

除了 <<<<<<<, ======= 和 >>>>>>> 标记之外，它还使用另一个 ||||||| 标记，后跟原始文本。您可以看出，原始文本只是陈述了一个事实，而您这边只是屈服于这个声明并放弃了，而另一边则试图采取更积极的态度。通过查看原始文本，有时您可以提出更好的解决方案。

如何解决冲突

看到冲突后，您可以做两件事

决定不合并。您唯一需要清理的是将索引文件重置到 HEAD 提交以撤销第 2 点，并清理第 2 点和第 3 点对工作树所做的更改；可以使用 git merge --abort 来完成此操作。
解决冲突。Git 将在工作树中标记冲突。编辑文件使其符合要求，并将其 git add 到索引。使用 git commit 或 git merge --continue 来完成操作。后一个命令在调用 git commit 之前检查是否有（中断的）合并正在进行。

您可以使用多种工具来处理冲突

使用合并工具。git mergetool 用于启动图形合并工具，它将帮助您完成合并。
查看差异。git diff 将显示一个三方差异，突出显示 HEAD 和 MERGE_HEAD 版本的更改。git diff AUTO_MERGE 将显示您目前为解决文本冲突所做的更改。
查看每个分支的差异。git log --merge -p <path> 将首先显示 HEAD 版本的差异，然后是 MERGE_HEAD 版本的差异。
查看原始文件。git show :1:filename 显示共同祖先，git show :2:filename 显示 HEAD 版本，git show :3:filename 显示 MERGE_HEAD 版本。

示例

将分支 fixes 和 enhancements 合并到当前分支之上，进行章鱼合并
```
$ git merge fixes enhancements
```
将分支 obsolete 合并到当前分支，使用 ours 合并策略
```
$ git merge -s ours obsolete
```
将分支 maint 合并到当前分支，但不要自动创建新提交
```
$ git merge --no-commit maint
```
这可以在您想要在合并中包含更多更改，或者想要编写自己的合并提交消息时使用。

您应避免滥用此选项以偷偷地将大量更改引入合并提交。诸如增加发布/版本名称等小型修复是可以接受的。

合并策略

合并机制（git merge 和 git pull 命令）允许使用 -s 选项选择后端 合并策略。一些策略也可以接受它们自己的选项，可以通过将 -X<option> 参数传递给 git merge 和/或 git pull 来传递。

ort

这是拉取或合并一个分支时的默认合并策略。此策略只能使用三方合并算法解决两个头。当存在多个可用于三方合并的共同祖先时，它会创建共同祖先的合并树，并将其用作三方合并的参考树。根据对 Linux 2.6 内核开发历史中实际合并提交的测试，据报道这会导致更少的合并冲突，而不会导致错误合并。此外，此策略可以检测和处理涉及重命名的合并。它不使用检测到的复制。此算法的名称是首字母缩略词（“Ostensibly Recursive’s Twin”，表面上是递归的双胞胎），源于它是作为先前默认算法 recursive 的替代品而编写的事实。

在路径是子模块的情况下，如果合并一侧使用的子模块提交是合并另一侧使用的子模块提交的后代，Git 会尝试快进到后代。否则，Git 会将此情况视为冲突，并建议一个冲突提交的后代子模块提交作为解决方案，如果存在的话。

ort 策略可以接受以下选项：

ours

此选项强制冲突的块通过偏向我们的版本自动干净地解决。来自另一棵树中与我们这边不冲突的更改会反映在合并结果中。对于二进制文件，整个内容取自我们这边。

这不应与 ours 合并策略混淆，后者根本不查看其他树包含什么。它丢弃了其他树所做的所有事情，声明 我们的 历史包含了其中发生的所有事情。

theirs

这与 ours 相反；请注意，与 ours 不同，没有 theirs 合并策略来混淆此合并选项。

ignore-space-change

ignore-all-space

ignore-space-at-eol

ignore-cr-at-eol

为了三方合并，将带有指示类型空白更改的行视为未更改。与一行中的其他更改混合的空白更改不会被忽略。另请参阅 git-diff[1] -b、-w、--ignore-space-at-eol 和 --ignore-cr-at-eol。

如果*他们的*版本只引入了行的空白符更改，则使用*我们的*版本；
如果*我们的*版本引入了空白符更改但*他们的*版本包含了实质性更改，则使用*他们的*版本；
否则，合并按常规方式进行。

renormalize

这会对需要三方合并的任何文件的所有三个阶段执行虚拟检出和检入。此选项旨在用于合并具有不同清理过滤器或行尾规范化规则的分支。有关详细信息，请参阅 gitattributes[5] 中的“合并具有不同检入/检出属性的分支”部分。

no-renormalize

禁用 renormalize 选项。这会覆盖 merge.renormalize 配置变量。

find-renames[=<n>]

开启重命名检测，可选地设置相似度阈值。这是默认设置。它会覆盖 merge.renames 配置变量。另请参阅 git-diff[1] --find-renames。

rename-threshold=<n>

已弃用的 find-renames=<n> 同义词。

no-renames

关闭重命名检测。这会覆盖 merge.renames 配置变量。另请参阅 git-diff[1] --no-renames。

histogram

已弃用的 diff-algorithm=histogram 同义词。

patience

已弃用的 diff-algorithm=patience 同义词。

diff-algorithm=(histogram|minimal|myers|patience)

合并时使用不同的 diff 算法，这有助于避免因不重要的匹配行（例如来自不同函数的括号）而导致的错误合并。另请参阅 git-diff[1] --diff-algorithm。请注意，ort 默认为 diff-algorithm=histogram，而常规 diff 当前默认为 diff.algorithm 配置设置。

subtree[=<path>]

此选项是 subtree 策略的一种更高级形式，其中策略会猜测在合并时如何移动两棵树以使其相互匹配。相反，指定的路径被添加前缀（或从开头剥离），以使两棵树的形状匹配。

recursive

这现在是 ort 的同义词。它在 v2.49.0 之前是一个替代实现，但在 v2.50.0 中被重定向为表示 ort。先前的递归策略是 Git v0.99.9k 到 v2.33.0 之间解决两个头部的默认策略。

resolve

这只能使用三向合并算法解决两个头部（即当前分支和你拉取的另一个分支）。它尝试仔细检测交叉合并歧义。它不处理重命名。

octopus

这解决了两个以上头部的情况，但拒绝进行需要手动解决的复杂合并。它主要用于将主题分支头部捆绑在一起。这是拉取或合并多个分支时的默认合并策略。

ours

这解决了任意数量的头部，但合并的结果树始终是当前分支头部的树，有效地忽略了所有其他分支的所有更改。它旨在用于取代侧分支的旧开发历史。请注意，这与 ort 合并策略的 -Xours 选项不同。

subtree

这是一个修改过的 ort 策略。当合并树 A 和树 B 时，如果 B 对应于 A 的子树，则 B 首先会调整以匹配 A 的树结构，而不是在相同级别读取树。这种调整也会应用于共同祖先树。

对于使用三方合并的策略（包括默认的 ort），如果某个更改在两个分支上都进行了，但后来在一个分支上被撤销，则该更改将出现在合并结果中；有些人觉得这种行为令人困惑。这种情况发生是因为在执行合并时只考虑了头和合并基础，而不是单独的提交。因此，合并算法将撤销的更改视为没有更改，并替换为已更改的版本。

配置

branch.<name>.mergeOptions: 设置合并到分支 <name> 的默认选项。语法和支持的选项与 git merge 相同，但目前不支持包含空白字符的选项值。

本节中此行以上的所有内容均未包含在 git-config[1] 文档中。以下内容与该文档中的内容相同

merge.conflictStyle

指定合并时冲突块写入工作树文件的方式。默认是“merge”，它显示一个 <<<<<<< 冲突标记，一方所做的更改，一个 ======= 标记，另一方所做的更改，然后是一个 >>>>>>> 标记。另一种样式，“diff3”，在 ======= 标记之前添加一个 ||||||| 标记和原始文本。“merge”样式倾向于产生比 diff3 更小的冲突区域，这既因为排除了原始文本，也因为当两边的一部分行匹配时，它们只是被从冲突区域中拉出。另一种替代样式，“zdiff3”，类似于 diff3，但当匹配行出现在冲突区域的开头或结尾附近时，它会从冲突区域中移除两边匹配的行。

merge.defaultToUpstream

如果调用 merge 时没有 commit 参数，则使用当前分支配置的上游分支，通过其远程跟踪分支中存储的最后观察值进行合并。branch.<current branch>.merge 中命名远程 branch.<current-branch>.remote 的分支的值会被查询，然后它们通过 remote.<remote>.fetch 映射到它们对应的远程跟踪分支，并将这些跟踪分支的尖端进行合并。默认为 true。

merge.ff

默认情况下，当合并一个作为当前提交的后代提交时，Git 不会创建额外的合并提交。相反，当前分支的尖端会快进。当设置为 false 时，此变量会告诉 Git 在这种情况下创建额外的合并提交（等同于从命令行给出 --no-ff 选项）。当设置为 only 时，只允许此类快进合并（等同于从命令行给出 --ff-only 选项）。

merge.verifySignatures

如果为 true，则等同于 --verify-signatures 命令行选项。有关详细信息，请参阅 git-merge[1]。

merge.branchdesc

除了分支名称之外，还用与它们关联的分支描述文本填充日志消息。默认为 false。

merge.log

除了分支名称之外，还会用最多指定数量的实际合并提交的单行描述填充日志消息。默认为 false，true 是 20 的同义词。

merge.suppressDest

通过将匹配集成（integration）分支名称的 glob 添加到此多值配置变量中，计算出的合并到这些集成分支的默认合并消息将省略标题中的“into <branch-name>”。

空值元素可用于清除从先前配置条目累积的 glob 列表。当没有定义 merge.suppressDest 变量时，为了向后兼容，使用默认值 master。

merge.renameLimit

在合并过程中，重命名检测的穷举部分要考虑的文件数量。如果未指定，则默认为 diff.renameLimit 的值。如果 merge.renameLimit 和 diff.renameLimit 都未指定，则当前默认为 7000。如果关闭了重命名检测，此设置无效。

merge.renames

Git 是否检测重命名。如果设置为 false，则禁用重命名检测。如果设置为 true，则启用基本重命名检测。默认为 diff.renames 的值。

merge.directoryRenames

Git 是否检测目录重命名，这会影响历史一边向目录中添加新文件时，如果该目录在历史的另一边被重命名，则合并时会发生什么。可能的值有

false: 禁用目录重命名检测，这意味着此类新文件将保留在旧目录中。
true: 启用目录重命名检测，这意味着此类新文件将被移动到新目录中。
conflict: 将为此类路径报告冲突。

如果 merge.renames 为 false，则 merge.directoryRenames 将被忽略并视为 false。默认为 conflict。

merge.renormalize

告诉 Git 仓库中文件的规范表示形式随着时间的推移发生了变化（例如，较早的提交使用 CRLF 行尾记录文本文件，但最近的提交使用 LF 行尾）。在此类仓库中，对于每个需要三方内容合并的文件，Git 可以在执行合并之前将提交中记录的数据转换为规范形式，以减少不必要的冲突。有关更多信息，请参阅 gitattributes[5] 中的“合并具有不同检入/检出属性的分支”部分。

merge.stat

是否在合并结束时打印 ORIG_HEAD 和合并结果之间的 diffstat。默认为 true。

merge.autoStash

当设置为 true 时，在操作开始前自动创建一个临时暂存条目，并在操作结束后应用。这意味着您可以在脏工作树上运行合并。但是，请谨慎使用：成功合并后的最终暂存应用可能会导致非平凡的冲突。此选项可以被 git-merge[1] 的 --no-autostash 和 --autostash 选项覆盖。默认为 false。

merge.tool

控制 git-mergetool[1] 使用哪个合并工具。下面的列表显示了有效的内置值。任何其他值都被视为自定义合并工具，并且需要定义相应的 mergetool.<tool>.cmd 变量。

merge.guitool

当指定 -g/--gui 标志时，控制 git-mergetool[1] 使用哪个合并工具。下面的列表显示了有效的内置值。任何其他值都被视为自定义合并工具，并且需要定义相应的 mergetool.<guitool>.cmd 变量。

araxis
bc
codecompare
deltawalker
diffmerge
diffuse
ecmerge
emerge
examdiff
guiffy
gvimdiff
kdiff3
meld
nvimdiff
opendiff
p4merge
smerge
tkdiff
tortoisemerge
vimdiff
vscode
winmerge
xxdiff

merge.verbosity

控制递归合并策略显示的输出量。级别 0 除了检测到冲突时的最终错误消息外不输出任何内容。级别 1 仅输出冲突，级别 2 输出冲突和文件更改。级别 5 及以上输出调试信息。默认级别为 2。可以通过 GIT_MERGE_VERBOSITY 环境变量覆盖。

merge.<driver>.name

为自定义低级合并驱动程序定义一个人类可读的名称。有关详细信息，请参阅 gitattributes[5]。

merge.<driver>.driver

定义实现自定义低级合并驱动程序的命令。有关详细信息，请参阅 gitattributes[5]。

merge.<driver>.recursive

命名一个低级合并驱动程序，用于在共同祖先之间执行内部合并时使用。有关详细信息，请参阅 gitattributes[5]。

另请参阅

git-fmt-merge-msg[1], git-pull[1], gitattributes[5], git-reset[1], git-diff[1], git-ls-files[1], git-add[1], git-rm[1], git-mergetool[1]

Git[1] 套件的一部分

设置和配置

获取和创建项目

基本快照

分支与合并

共享和更新项目

检查和比较

打补丁

调试

电子邮件

外部系统

服务器管理

指南

管理

底层命令

名称

概要

描述

选项