为什么 Git 合并时有时会创建提交，有时不会？

Question

当我从另一个分支合并到当前工作区时，使用git merge命令时，Git有时会创建一个新的提交：

Merge remote-tracking branch xxx into xxx

有时候，它并不会：

Fast-forward
... src files ...

那么是什么决定了是否应该创建提交？

- user972946

Answer 1

所谓的“快进合并”不会产生提交，而其他合并（通常称为“章鱼合并”（现在你知道为什么Github的吉祥物是章鱼猫了吧））则会产生提交。

基本上，“快进合并”发生在您的分支没有分叉的情况下。

假设您想要将一个名为foo的分支合并到master分支中。如果这些分支没有分叉，那么您将拥有以下历史记录（每个*代表一个提交）：

*---* (master)
     \
      *---*---* (foo)

在这种情况下，合并是< strong> 快进（fast-forward）的，因为（根据图形理论，这是git图形的基础），< code> master 可以从< code> foo 到达。换句话说，您只需将< code> master 引用移动到< code> foo ，就完成了：

*---*
     \
      *---*---* (master, foo)

当你的分支开始分叉：

*---*---* (master)
     \
      *---*---* (foo)

你需要创建一个提交来“合并”这两个分支：

                ↓
*---*---*-------* (master)
     \         / 
      *---*---* (foo)

箭头指向的提交是合并提交，并具有两个父提交（以前的master分支尖端和当前的foo分支尖端)。

请注意，您可以使用--no-ff选项强制Git为快进合并创建合并提交。

我强烈推荐阅读http://think-like-a-git.net/，以更好地理解图论如何应用于Git（您不需要了解图论，网站上所需的一切都在网站上），这将使使用Git变得非常容易 :)

- Geoffrey Bachelet

Answer 2

您可以使用--no-ff选项来强制创建一个新的提交，以避免快进。

- user3021843

---

谢谢，但我的问题是为什么Git认为制作合并提交比简单地快进工作区更合适？ - user972946

Answer 3

快进（fast forward）意味着提交已经发生并存储在您的日志中，而您的HEAD（指针）已向前移动到该提交。您可以在这里查看合并行为。

- hyleaus

---

谢谢，但我的问题是为什么 Git 认为创建一个合并提交比简单地快进工作区更合适？ - user972946

你正在你所在的分支上进行更改吗？如果你已经在本地对你拉取的repo进行了更改，合并提交将会处理这些更改，而快进则只是移动指针。 - hyleaus

Answer 4

当没有传入 --no-ff 参数时，如果你要合并的分支的头部是已合并分支的祖先，git 就不会创建新的提交记录。在这种情况下（没有 --no-ff 参数），它只是移动 HEAD 指针（也就是所谓的快进操作）。

- Alexey Kozhevnikov

Answer 5

来自文档的摘录：

快进合并

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

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

真正的合并

除了快进合并（见上文），要合并的分支必须通过一个合并提交将它们绑定在一起，该提交具有它们两个作为父级。

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

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

- HEAD指针保持不变。 - MERGE_HEAD引用被设置为指向另一个分支头。 - 清洁合并的路径在索引文件和您的工作树中都得到更新。 - 对于冲突的路径，索引文件记录最多三个版本：阶段1存储来自共同祖先的版本，阶段2存储来自HEAD的版本，阶段3存储来自MERGE_HEAD的版本（您可以使用git ls-files -u检查这些阶段）。工作树文件包含“合并”程序的结果；即带有熟悉的冲突标记<<< === >>>的三路合并结果。

不进行其他更改。特别是，在开始合并之前您所拥有的本地修改将保持不变，它们的索引条目也将保持不变，即与HEAD匹配。

如果您尝试了导致复杂冲突的合并，并希望重新开始，则可以使用git merge --abort进行恢复。

- jumping_monkey