English ▾ 主题 ▾ 最新版本 ▾ git-merge 上次更新于 2.49.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 尾部。 签名的含义取决于您要提交到的项目。 例如，它可能证明提交者有权根据项目的许可提交作品，或者同意某些贡献者声明，例如开发者原创证书。 （有关 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 选项，则会使用内置的策略列表（合并单个 head 时使用 ort，否则使用 octopus）。

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

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

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

验证要合并的侧分支的 tip commit 是否使用有效密钥签名，即具有有效 uid 的密钥：在默认信任模型中，这意味着签名密钥已由受信任的密钥签名。如果侧分支的 tip commit 未使用有效密钥签名，则合并将中止。

--summary
--no-summary

与 --stat 和 --no-stat 同义；这些已弃用，将在未来版本中删除。

-q
--quiet

安静模式。隐含 --no-progress。

-v
--verbose

详细模式。

--progress
--no-progress

显式地打开/关闭进度显示。如果未指定任何一个，则当标准错误连接到终端时，将显示进度。请注意，并非所有合并策略都可能支持进度报告。

--autostash
--no-autostash

在操作开始之前自动创建一个临时储藏条目，将其记录在 ref MERGE_AUTOSTASH 中，并在操作结束后应用它。这意味着你可以在一个脏的工作树上运行该操作。但是，请谨慎使用：在成功合并后最终的储藏应用可能会导致非平凡的冲突。

--allow-unrelated-histories

默认情况下，git merge 命令拒绝合并不共享共同祖先的历史记录。当合并两个独立开始的项目的历史记录时，可以使用此选项来覆盖此安全措施。由于这种情况非常罕见，因此不存在默认启用此功能的配置变量，也不会添加。

-m <msg>

设置用于合并提交的提交消息（如果创建了合并提交）。

如果指定了 --log，则要合并的提交的 shortlog 将附加到指定的消息。

git fmt-merge-msg 命令可用于为自动化的 git merge 调用提供良好的默认值。自动化的消息可以包含分支描述。

--into-name <branch>

准备默认的合并消息，就像合并到分支 <branch> 一样，而不是合并到的实际分支的名称。

-F <file>
--file=<file>

读取用于合并提交的提交消息（如果创建了合并提交）。

如果指定了 --log，则要合并的提交的 shortlog 将附加到指定的消息。

--rerere-autoupdate
--no-rerere-autoupdate

在 rerere 机制重用记录的冲突解决方案以更新工作树中的文件之后，允许它也使用解决方案的结果更新索引。--no-rerere-autoupdate 是一种很好的方法来双重检查 rerere 所做的事情，并在使用单独的 git add 命令将结果提交到索引之前捕获潜在的错误合并。

--overwrite-ignore
--no-overwrite-ignore

静默地覆盖合并结果中被忽略的文件。这是默认行为。使用 --no-overwrite-ignore 来中止。

--abort

中止当前冲突解决过程，并尝试重建合并前的状态。如果存在 autostash 条目，则将其应用于工作树。

如果在合并开始时存在未提交的工作树更改，则在某些情况下，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>…​

要合并到我们的分支中的提交，通常是其他分支的 head。指定多个提交将创建一个具有两个以上父级的合并（亲切地称为章鱼式合并）。

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

当指定 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.”（已是最新）。

快速向前合并

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

可以使用 --no-ff 选项禁止此行为。

真实合并

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

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

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

  1. HEAD 指针保持不变。

  2. MERGE_HEAD ref 设置为指向另一个分支的 head。

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

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

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

  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 的替代品。

如果路径是一个子模块，如果合并一方使用的子模块提交是合并另一方使用的子模块提交的后代，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] 中的 "Merging branches with differing checkin/checkout attributes"。

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

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

对于作为子模块的路径，与 ort 相同的注意事项适用于此策略。

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

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

这解决了任意数量的头部，但合并的结果树始终是当前分支头部，有效地忽略了来自所有其他分支的所有更改。它旨在用于取代侧分支的旧开发历史记录。请注意，这与 recursive 合并策略的 -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，则合并为当前分支配置的上游分支，方法是使用存储在其远程跟踪分支中的最后观察到的值。 查询 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 时，在操作开始之前自动创建一个临时储藏条目，并在操作结束后应用它。 这意味着您可以在一个脏的工作树上运行合并。 但是，请谨慎使用：成功合并后的最终储藏应用可能会导致非常重要的冲突。 可以通过 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