简体中文 ▾ Topics ▾ Latest version ▾ git-merge last updated in 2.54.0

名称

git-merge - 将两个或多个开发历史合并在一起

概述

'git merge' [-n] [--stat] [--no-commit] [--squash] [--[no-]edit]
	[--no-verify] [-s <策略>] [-X <策略选项>] [-S[<键 ID>]]
	[--[no-]allow-unrelated-histories]
	[--[no-]rerere-autoupdate] [-m <信息>] [-F <文件>]
	[--into-name <分支>] [<提交>…​］
'git merge' (--continue |--abort |--quit)

描述

将指定的提交内容（从它们的历史与当前分支相分离时起）并入当前分支。 这条命令被 "git pull "用来合并另一个仓库的改动，也可以用手将一个分支的改动合并到另一个分支。

假设存在以下历史，且当前分支为 master：

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

然后 git merge topic 将重现 topic 分支从 master（即 E）分流到 master 之上的当前提交（ C ）所做的修改，并将结果与两个父提交的名称和用户描述修改的日志信息一起记录在一个新提交中。在操作之前，ORIG_HEAD 被设置为当前分支（C）的顶端。

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

如果出现无法自动解决的冲突，或者在启动合并时提供了 --no-commit 选项，合并就会停止。这时可以运行 git merge --abort 或 git merge --continue 。

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

Warning
 警告：在非重要的未提交的修改中运行 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=<模式>

这个选项决定了在提交前如何清理合并信息。更多细节见git-commit[1]。此外，如果 <模式> 的值为 scissors，在发生合并冲突时，scissors将被附加到 "MERGE_MSG "上，然后传递给提交机制。

--ff
--no-ff
--ff-only

指定当被合并的历史已经是当前历史的后代时，如何处理合并的问题。 默认为 --ff，除非合并的是一个有注释的（可能是有签名的）标签，在这种情况下，--no-ff 假设这个标签并没有存储在 refs/tags/ 层次结构中的自然位置。

如果使用 --ff，可能的话，以快进方式解决合并问题（只更新分支指针以匹配合并后的分支；不创建合并提交）。 当不可能时（当合并的历史不是当前历史的后代），创建一个合并提交。

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

使用 --ff-only，在可能的情况下，以快进的方式解决合并的问题。 当不可能时，拒绝合并并以非零状态退出。

-S[<keyid>]
--gpg-sign[=<键 ID>]
--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项目使用的证书，请参见http://developercertificate.org）。 请查阅你要贡献的项目的文档或领导层，以了解该项目如何使用签名。

--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 事件hook。 当给定 --no-verify 时，这些将不会执行。 参见 githooks[5]。

-s <策略>
--strategy=<策略>

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

-X <选项>
--strategy-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 <消息>

设置用于合并提交的提交信息（如果创建了一个的话）。

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

git fmt-merge-msg 命令可以为自动 git merge 调用提供一个良好的默认值。自动信息可以包括分支描述。

--into-name <分支>

准备默认的合并信息，就像合并到分支 <分支> 一样，而不是真正要合并的分支名称。

-F <文件>
--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 来结束当前合并（见下文“如何解决冲突”部分）。

<提交>…​

提交，通常是其他分支负责人，合并到我们的分支中。 指定多个提交将创建具有两个以上父项的合并（亲切地称为八爪/多路合并）。

如果命令行没有给出提交，则合并当前分支被配置为上游的远程跟踪分支。 参见本手册页的配置部分。

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

合并前检查

在应用外部的修改之前，你应该把自己的工作做好，并在本地提交，这样在有冲突的时候就不会被打乱了。 参见 git-stash[1]。 git pul 和 git merge 会在本地未提交的修改与 git pull/git merge 可能需要更新的文件重叠时会不做任何操作，立即停止。

为了避免在合并提交中记录不相关的变化，git pull 和 git merge 也会在相对于 HEAD 提交的索引中存在任何变化时中止。 (根据使用的合并策略，这一规则可能存在特殊的狭义例外，但一般来说，索引必须与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"程序相同的样式来呈现这样一个有冲突的大块，像这样：

这里是与共同的祖先相比没有变化的行。
祖先没有变化，或者因为只有一方发生了变化而得到干净的解决、
或者因为两边都有相同的变化而被干净地解决了。
<<<<<<< yours:sample.txt
冲突的解决是困难的；
让我们去购物吧。
=======
Git让冲突解决变得简单。
>>>>>>> theirs:sample.txt
而这里是另一行干净利落的解决或未修改的内容。

发生一对冲突变化的区域被标记为 <<<<<<<、======= 和 >>>>>>>。 ======= 之前的部分通常是你做的修改，而之后的部分通常是别人的修改。

默认的格式并不显示原文在冲突区说了什么。 你无法知道有多少行被删除，并被替换成你方的芭比娃娃的言论。 你唯一能知道的是，你方想说这很难，你更愿意去购物，而另一方则想说这很容易。

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

这里是与共同的祖先相比没有变化的行。
祖先没有变化，或者因为只有一方发生了变化而得到了干净的解决、
<<<<<<< yours:sample.txt
或干净地解决了，因为双方都以同样的方式改变了。
冲突的解决是很难的；
让我们去购物吧。
||||||| base:sample.txt
或干净利落地解决了，因为双方的变化都一样。
冲突的解决是很难的。
=======
或干净利落地解决了，因为双方都有相同的变化。
Git使冲突解决变得容易。
>>>>>>> theirs:sample.txt
而这里是另一行被干净地解决或未修改的。

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

这里是与共同的祖先相比没有变化的行。
祖先没有变化，或者因为只有一方发生了变化而得到干净的解决、
或者因为两边都有相同的变化而被干净地解决了。
<<<<<<< yours:sample.txt
冲突的解决是困难的；
让我们去购物吧。
||||||| base:sample.txt
或干净利落地解决，因为双方的变化都一样。
冲突的解决是很难的。
=======
Git 让冲突解决变得简单。
>>>>>>> theirs:sample.txt
而这里是另一行被干净地解决或未修改的内容。

除了 <<<<<<<、======= 和 >>>>>>> 标记外，它还使用了另一个 ||||||| 标记，后面是原文。 你可以看出，原文只是陈述了一个事实，而你的一方只是屈服于这个陈述而放弃了，而另一方则试图有一个更积极的态度。 你有时可以通过查看原文得出一个更好的解决方案。

如何解决冲突

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

  • 决定不进行合并。 唯一需要清理的是将索引文件重置为 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 <路径> 将首先显示 HEAD 版本的差异，然后是 MERGE_HEAD 版本。

  • 看一下原件。 git show :1:filename 显示共同的祖先，git show :2:filename 显示 HEAD 版本，git show :3:filename 显示 MERGE_HEAD 版本。

实例

  • 合并分支 fixes 和 enhancements 到当前分支之上，进行多路合并：

    $ git merge 修复增强功能

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

    $ git merge -s ours obsolete

  • 合并分支 maint 到当前分支，但是我们不做自动创建新提交:

    $ git merge --no-commit maint

    当您想在合并中加入进一步的更改，或者您想手动编写合并提交信息时，就可以使用此功能。

    你应该避免滥用这个选项，它可以在合并提交中偷偷地进行仓库中实质性的修改。 小的修正，例如修改发布日志内容/版本名称，是推荐的。

合并战略

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

ort

这是拉取或合并一个分支时的默认合并策略。 这个策略只能使用三方合并算法解决两个头。 当有一个以上的共同祖先可用于三方合并时，它会创建一个共同祖先的合并树，并将其作为三方合并的参考树。 据报道，通过对Linux 2.6内核开发历史中的实际合并提交的测试，这导致了较少的合并冲突，而不会引起错误的合并。 此外，这个策略可以检测并处理涉及重命名的合并。 它并不使用检测到的副本。 这个算法的名字是一个缩写（"Ostensibly Recursive’s Twin"），来自于它是作为以前的默认算法 recursive 的替代而编写的。

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

ort 策略可以采取以下选项：

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=patience 的同义词。

patience

废弃的，diff-algorithm=patience 的同义词。

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

在合并时使用不同的差异算法，这可以帮助避免由于不重要的匹配行（比如不同函数的大括号）而发生的错误合并。 参见git-diff[1] --diff-algorithm。 注意，ort 特定 diff-algorithm=histogram，而 recursive 默认为 diff.algorithm 配置设置。

subtree[=<路径>]

这个选项是 子树 策略的更高级形式，该策略对两棵树在合并时必须如何移位以相互匹配进行猜测。 相反，指定的路径是前缀（或从开始剥离），以使两棵树的形状相匹配。

recursive

它现在是 ort 的同义词。它在 v2.49.0 之前是一个替代实现，但从 v2.50.0 起被重定向为表示 ort。此前的 recursive 策略曾在 Git v0.99.9k 至 v2.33.0 期间作为合并两个 head 的默认策略。

resolve

这只能用三方合并算法解决两个头（即当前分支和你拉来的另一个分支）。 它试图仔细检测纵横交错的合并歧义。 它不处理重名。

octopus

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

ours

这可以解决任何数量的头，但合并的结果总是当前分支头的树，有效地忽略了所有其他分支的变化。 它是用来取代侧边分支的旧开发历史的。 注意，这与 recursive 合并策略的-Xours选项不同。

subtree

这是一个修正的 ort 策略。当合并树A和B时，如果B对应于A的子树，B首先被调整为与A的树结构相匹配，而不是在同一级别读取树。这种调整也是针对共同祖先树进行的。

对于使用三方合并的策略（包括默认的 ort 策略），如果在两个分支上都做了修改，但后来在其中一个分支上被撤销，那么这个修改就会出现在合并后的结果中；有些人觉得这种行为令人困惑。 出现这种情况是因为在执行合并时只考虑头部和合并基数，而不是单个提交。 因此，合并算法认为被恢复的修改根本就没有变化，而是用被修改的版本来代替。

配置

分支 .<名字>.合并操作选项

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

本节中这一行以上的内容并不包括在 git-config[1] 文档中。下面的内容与那里的内容相同：

merge.conflictStyle

指定合并时将冲突块写入工作区树文件的样式。 默认样式是 "merge"（合并），它会显示一个 <<<<<<< 冲突标记、一方所做的更改、一个 ======= 标记、另一方所做的更改，然后是一个 >>>>>>> 标记。 另一种样式 "diff3" 会在 "=======" 标记前添加 "|||||||" 标记和原文。 “合并” 样式产生的冲突区域往往比 diff3 小，一是因为不包含原始文本，二是因为当双方有子集行匹配时，这些行会被从冲突区域中拉出。 另一种样式是 "zdiff3"，它与 diff3 类似，但会在冲突区域的开头或结尾附近出现匹配行时，将这些匹配行从冲突区域中移除。

merge.defaultToUpstream

如果调用 merge 时没有任何提交参数，则通过使用存储在其远程跟踪分支中的最后观察值来合并为当前分支配置的上游分支。 branch.<当前分支>.merge 的值会被查阅，这些值命名了由 branch.<当前分支>.remote 命名的远程分支，然后通过 remote.<远程仓库>.fetch 将它们映射到相应的远程跟踪分支，并合并这些跟踪分支的提示。默认为 true。

merge.ff

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

merge.verifySignatures

如果为真，这等同于 --verify-signatures 命令行选项。详见 git-merge[1]。

merge.branchdesc

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

merge.log

除了分支名称外，在日志信息中最多加入指定数量的被合并的实际提交的单行描述。 默认为 false，true 是2 0 的同义词。

merge.suppressDest

通过向这个多值配置变量添加一个匹配集成分支名称的通配符，为合并到这些集成分支计算的默认合并消息将在其标题中省略 "into <分支名>"。

一个空值的元素可以用来清除以前配置项积累的globs列表。 当没有定义 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 "时，在操作开始前自动创建一个临时的贮藏库条目，并在操作结束后应用它。 这意味着你可以在一个肮脏的工作区上运行merge。 然而，要小心使用：在成功的合并之后，最后的贮藏库应用可能会导致非实质性的冲突。 这个选项可以被 git-merge[1] 的 --no-autostash 和 --autostash 选项覆盖。 默认为 false。

merge.tool

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

merge.guitool

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

araxis

使用 Araxis 合并（需要图形会话）

bc

使用 Beyond Compare（需要图形会话）

bc3

使用 Beyond Compare（需要图形会话）

bc4

使用 Beyond Compare（需要图形会话）

codecompare

使用代码比较（需要图形会话）

deltawalker

使用 DeltaWalker（需要图形会话）

diffmerge

使用 DiffMerge（需要图形会话）

diffuse

使用 Diffuse（需要图形会话）

ecmerge

使用 ECMerge（需要图形会话）

emerge

使用 Emacs 的 Emerge

examdiff

使用 ExamDiff Pro（需要图形会话）

guiffy

使用 Guiffy 的 Diff 工具（需要图形会话）

gvimdiff

使用 gVim（需要图形会话）和自定义布局（参见 git help mergetool 的 BACKEND SPECIFIC HINTS 部分）

gvimdiff1

使用 gVim（需要图形会话），采用双窗格布局（本地和远程）

gvimdiff2

使用 gVim（需要图形会话），采用 3 个面板布局（本地、合并和远程）

gvimdiff3

使用 gVim（需要图形会话），只显示 MERGED 文件

kdiff3

使用 KDiff3（需要图形会话）

meld

使用带可选 auto merge 功能的 Meld（需要图形会话）（请参阅 git help mergetool 的 配置 部分）

nvimdiff

使用带有自定义布局的 Neovim（请参阅 git help mergetool 的 BACKEND SPECIFIC HINTS 部分）

nvimdiff1

使用 Neovim 的双窗格布局（本地和远程）

nvimdiff2

使用 Neovim 的 3 个面板布局（本地、合并和远程）

nvimdiff3

使用 Neovim，只显示合并文件

opendiff

使用文件合并（需要图形会话）

p4merge

使用 HelixCore P4Merge（需要图形会话）

smerge

使用 Sublime Merge（需要图形会话）

tkdiff

使用 TkDiff（需要图形会话）

tortoisemerge

使用 TortoiseMerge（需要图形会话）

vimdiff

使用自定义布局的 Vim（请参阅 git help mergetool 的 后端特定提示 部分）

vimdiff1

使用双窗格布局（本地和远程）的 Vim

vimdiff2

使用 Vim 的 3 个面板布局（本地、合并和远程）

vimdiff3

使用 Vim，只显示合并后的文件

vscode

使用代码比较（需要图形会话）

winmerge

使用 WinMerge（需要图形会话）

xxdiff

使用 xxdiff（需要图形会话）

merge.verbosity

控制递归合并策略所显示的输出量。 0级除了在检测到冲突时有一个最终的错误信息外，什么都不输出。1级只输出冲突，2级输出冲突和文件变化。 5级及以上输出调试信息。 默认是第2级。 可以通过 GIT_MERGE_VERBOSITY 环境变量覆盖。

合并.<driver>.name

为自定义的低级合并驱动定义了一个具有可读性的名字。 详情见 gitattributes[5]。

merge.<driver>.driver

定义实现自定义低级合并驱动程序的命令。详见链接 gitattributes[5]。

merge.<驱动程序>.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] 文档