Git

git-merge 最后更新于 2.53.0

名称

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

概要

git merge [-n] [--stat] [--compact-summary] [--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) 所做的更改，并将其记录在一个新提交中，同时包含两个父提交的名称和用户描述更改的日志消息。操作之前，ORIG_HEAD 设置为当前分支的尖端 (G)。

          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 尾部。Signoff 的含义取决于您正在提交到的项目。例如，它可能证明提交者有权在项目的许可证下提交工作，或者同意某些贡献者表示，例如开发者证书（请参阅 https://developercertificate.org 获取 Linux 内核和 Git 项目使用的证书）。请查阅您贡献项目的文档或领导层，以了解该项目如何使用 Signoff。

可以使用 --no-signoff 选项来抵消命令行中较早的 --signoff 选项。

Git 现在没有（将来也不会有）用于默认启用 --signoff 命令行选项的配置变量；详见 gitfaq[7] 中的 commit.signoff 条目。
--stat
-n
--no-stat: 在合并结束时显示一个差异统计。差异统计也由配置选项 merge.stat 控制。

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

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

使用 --squash 时，不允许使用 --commit，否则将失败。
--verify
--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>...: 提交，通常是其他分支头，合并到我们的分支。指定多个提交将创建一个具有两个以上父级的合并（俗称 Octopus 合并）。

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

当指定 FETCH_HEAD（且没有其他提交）时，由先前调用 git fetch 记录在 .git/FETCH_HEAD 文件中以进行合并的分支将被合并到当前分支。

合并前检查

在应用外部更改之前，您应该整理好自己的工作并在本地提交，这样在发生冲突时就不会被覆盖。另请参阅 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 选项选择后端合并策略。一些策略还可以接受自己的选项，这些选项可以通过向 git merge 和/或 git pull 传递 -X<option> 参数来传递。

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>]

此选项是子目录策略的高级形式，在该策略中，合并时策略会猜测两个树必须如何偏移才能匹配。相反，指定的路径会作为前缀（或从开头剥离）以使两个树的形状匹配。

recursive

这现在是 ort 的同义词。它直到 v2.49.0 都是一个替代实现，但在 v2.50.0 中被重定向为 ort。之前的 recursive 策略是从 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 值，然后通过 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 和合并结果之间是否打印任何内容。可能的值是

false: 什么都不显示。
true: 显示 git diff --diffstat --summary ORIG_HEAD。
compact: 显示 git diff --compact-summary ORIG_HEAD。

但任何无法识别的值（例如，Git 未来版本添加的值）都被视为 true，而不是触发错误。默认为 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] 套件的一部分

设置和配置

获取和创建项目

基本快照

分支与合并

共享和更新项目

检查和比较

打补丁

调试

电子邮件

外部系统

服务器管理

指南

管理

底层命令

名称

概要

描述

选项