Git
英语 ▾ 主题 ▾ 最新版本 ▾ git-merge 最后更新于 2.47.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 选项可用于接受自动生成的邮件（通常不建议这样做）。--edit（或 -e）选项在您从命令行使用 -m 选项提供草稿邮件并希望在编辑器中进行编辑时仍然有用。

较旧的脚本可能依赖于不允许用户编辑合并日志消息的历史行为。在他们运行 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[<keyid>]
--gpg-sign[=<keyid>]
--no-gpg-sign

使用 GPG 对生成的合并提交进行签名。keyid 参数是可选的，默认为提交者身份；如果指定，则必须粘贴到选项后面，没有空格。--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

默认情况下，会运行预合并和提交信息钩子。当给出--no-verify时，会绕过这些钩子。另请参见 githooks[5]。

-s <strategy>
--strategy=<strategy>

使用给定的合并策略；可以多次提供以指定它们应该尝试的顺序。如果没有-s选项，将使用内置策略列表（合并单个头时为ort，否则为octopus）。

-X <option>
--strategy-option=<option>

将合并策略特定的选项传递给合并策略。

--verify-signatures
--no-verify-signatures

验证正在合并的侧分支的顶端提交是否使用有效的密钥签名，即一个具有有效 UID 的密钥：在默认信任模型中，这意味着签名密钥已被受信任密钥签名。如果侧分支的顶端提交没有使用有效的密钥签名，则合并将被中止。

--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调用为合并记录在.git/FETCH_HEAD文件中的分支将合并到当前分支。

合并前检查

在应用外部更改之前，您应该将自己的工作整理好并提交到本地，这样如果出现冲突，它们就不会被覆盖。另请参见 git-stash[1]。当本地未提交的更改与git pull/git merge可能需要更新的文件重叠时，git pull和git merge将停止而不会执行任何操作。

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

如果所有命名的提交都是HEAD的祖先，git merge将提前退出，并显示“已更新”消息。

快进合并

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

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

真实合并

除了快进合并（见上文）之外，要合并的分支必须通过一个合并提交来绑定在一起，该合并提交将它们都作为其父节点。

一个协调了所有要合并的分支的更改的合并版本被提交，您的HEAD、索引和工作树被更新到它。只要它们不重叠，工作树中就可能存在修改；更新将保留它们。

当不清楚如何协调更改时，将发生以下情况

  1. HEAD指针保持不变。

  2. MERGE_HEAD引用被设置为指向另一个分支头。

  3. 干净合并的路径在索引文件和工作树中都被更新。

  4. 对于冲突的路径，索引文件记录最多三个版本：阶段 1 存储来自共同祖先的版本，阶段 2 来自HEAD，阶段 3 来自MERGE_HEAD（您可以使用git ls-files -u检查这些阶段）。工作树文件包含合并操作的结果；即 3 路合并结果，其中包含熟悉的冲突标记<<< === >>>。

  5. 一个名为AUTO_MERGE的引用被写入，指向一个与工作树的当前内容（包括文本冲突的冲突标记）相对应的树。请注意，此引用仅在使用ort合并策略时才会被写入（默认策略）。

  6. 没有其他更改。特别是，您在开始合并之前所做的本地修改将保持不变，它们在索引中的条目将保持原样，即与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

  • 使用 ours 合并策略将分支 obsolete 合并到当前分支

    $ git merge -s ours obsolete

  • 将分支 maint 合并到当前分支，但不要自动创建新的提交

    $ git merge --no-commit maint

    这可用于在你想将进一步的更改包含到合并中，或想编写自己的合并提交信息时使用。

    你应该避免滥用此选项，将大量更改偷偷地包含到合并提交中。较小的修正，例如更新发布/版本名称是可以接受的。

合并策略

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

ort

这是拉取或合并一个分支时的默认合并策略。此策略只能使用 3 路合并算法来解决两个头。当有多个可用于 3 路合并的公共祖先时，它会创建公共祖先的合并树，并将其用作 3 路合并的参考树。据报道，通过对实际合并提交（从 Linux 2.6 内核开发历史中提取）进行的测试，这种方法可以减少合并冲突，而不会导致错误合并。此外，该策略可以检测和处理涉及重命名的合并。它不使用检测到的复制。该算法的名称是一个首字母缩略词（“Ostensibly Recursive’s Twin”），源于它是在编写替代之前默认算法 recursive 的过程中诞生的。

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> 的弃用同义词。

subtree[=<path>]

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

recursive

这只能使用 3 路合并算法来解决两个头。当有多个可用于 3 路合并的公共祖先时，它会创建公共祖先的合并树，并将其用作 3 路合并的参考树。据报道，通过对实际合并提交（从 Linux 2.6 内核开发历史中提取）进行的测试，这种方法可以减少合并冲突，而不会导致错误合并。此外，这可以检测和处理涉及重命名的合并。它不使用检测到的复制。这是从 Git v0.99.9k 到 v2.33.0 版本中用于解决两个头的默认策略。

recursive 策略采用与ort 相同的选项。但是，还有三个ort 忽略的额外选项（上面没有记录），这些选项可能对recursive 策略有用

patience

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

diff-algorithm=[patience|minimal|histogram|myers]

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

no-renames

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

resolve

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

octopus

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

ours

这会解决任意数量的头，但合并结果树始终是当前分支头的树，实际上会忽略来自所有其他分支的所有更改。它用于替代边分支的旧开发历史记录。请注意，这不同于recursive 合并策略的 -Xours 选项。

subtree

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

对于使用 3 路合并的策略（包括默认策略ort），如果在一个分支上进行了更改，但在另一个分支上后来被还原，则该更改将出现在合并结果中；有些人发现这种行为令人困惑。发生这种情况是因为在执行合并时，只考虑头和合并基础，而不考虑各个提交。因此，合并算法认为还原的更改与没有更改一样，并替换为更改的版本。

配置

branch.<name>.mergeOptions

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

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

merge.conflictStyle

指定在合并时将冲突的块写入工作树文件的样式。默认值为“merge”，它显示一个<<<<<<<冲突标记、一方所做的更改、一个=======标记、另一方所做的更改，然后是一个>>>>>>>标记。另一种样式“diff3”添加了|||||||标记以及=======标记之前的原始文本。“merge”样式往往会产生比 diff3 更小的冲突区域，这是因为排除了原始文本，并且当两侧的一组行匹配时，它们只是从冲突区域中删除。另一种备选样式“zdiff3”类似于 diff3，但在冲突区域的开始或结束附近出现匹配行时，会从冲突区域中删除两侧的匹配行。

merge.defaultToUpstream

如果在不带任何提交参数的情况下调用 merge，则使用在它们各自的远程跟踪分支中存储的上次观察到的值，合并为当前分支配置的上游分支。将参考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

通过将匹配集成分支名称的 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 是否检测目录重命名，影响合并时如何处理添加到历史记录一方的目录中的新文件，而该目录在历史记录的另一方被重命名。如果 merge.directoryRenames 设置为“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 时，在操作开始之前自动创建临时隐藏条目，并在操作结束后应用它。这意味着您可以在脏工作树上运行 merge。但是，请谨慎使用：在成功合并后进行的最终隐藏应用可能会导致非平凡的冲突。此选项可以被 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

是 git[1] 套件的一部分

scroll-to-top