Git
英语 ▾ 主题 ▾ 版本 2.44.0 ▾ git-merge 上次更新于 2.44.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[<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 拖尾。签名的含义取决于你提交到的项目。例如，它可以证明提交者有权在项目的许可证下提交工作，或同意某些贡献者表示，例如开发者原产地证书。（请参阅 https://developercertificate.org，这是 Linux 内核和 Git 项目使用的证书。）查阅你正在为之做出贡献的项目的文档或领导层，以了解该项目如何使用签名。

--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 是一个很好的方法，可以在使用单独的 git add 将结果提交到索引之前，仔细检查 rerere 的操作并捕获潜在的错误合并。

--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 检查阶段）。工作树文件包含合并操作的结果；即，带有熟悉冲突标记 <<< === >>> 的三方合并结果。

  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 选项选择后端合并策略。某些策略还可以采用自己的选项，可以通过将 -X<option> 参数传递给 git merge 和/或 git pull 来传递这些选项。

ort

这是在拉取或合并一个分支时的默认合并策略。此策略只能使用三向合并算法解析两个头。当有多个公共祖先可用于三向合并时，它会创建一个公共祖先的合并树，并将其用作三向合并的参考树。据报道，在对从 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>]

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

recursive

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

递归策略采用与ort相同的选项。但是，ort忽略的三个其他选项（上面未记录）可能对递归策略有用

patience

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

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

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

no-renames

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

resolve

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

octopus

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

ours

它解析任意数量的头，但合并的结果树始终是当前分支头的树，有效地忽略了所有其他分支的所有更改。它用于取代侧分支的旧开发历史。请注意，这与递归合并策略的 -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>.remote 远程中的分支的 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

通过向此多值配置变量添加与集成分支名称匹配的 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，则在操作开始前自动创建一个临时暂存条目，并在操作结束后应用该条目。这意味着你可以在一个脏工作树上运行合并。但是，请谨慎使用：在成功合并后最终应用暂存可能会导致非平凡的冲突。此选项可以被 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

  • 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