Question

如果随后立即删除了源（功能）分支，则在--squash合并和--no-ff合并之间，关于存储库的最终状态是否有所不同？

-no-ff合并提交将包含与壁球合并提交相同的更改，对吗？

Answer 1

想象一下，提交作为图形中的节点（因为它们是图形中的节点）。

在执行其他任何操作之前，您会遇到以下情况：

...--F--G--H   <-- master
            \
             I--J--K   <-- feature

或者像这样：

...--F--G--H   <-- master
         \
          I--J--K   <-- feature

如果您现在选择运行git checkout master; git merge --no-ff feature，结果将是对master的新提交-即使下一个可用字母为L，我们也将其称为M进行合并。 —看起来像：

...--F--G--H---------M   <-- master
            \       /
             I--J--K   <-- feature

（或类似）。新提交M的第一个父级是现有提交H：以前是master的尖端的。新提交M的第二父级是现有提交K：以前（现在仍然是）feature的顶端。

（如果您的起始图看起来像第二个示例，其中feature与master共享的第一次提交是G而不是H，则{{1} }参数不是必需的。Git必须进行真正的合并，所以会这样。如果起始图看起来像第一个示例，则--no-ff会强制Git进行真正的合并，即使常见的起点提交已经是--no-ff的技巧了。）

如果您运行master而不是git merge --squash，则会得到以下信息：

git merge --no-ff

在这里我们可以调用新提交...--F--G--H---------S <-- master \ I--J--K <-- feature进行压缩，而不是S进行合并。就内容而言，提交M与S 非常相似。关键区别在于，提交M只有一个父对象：提交S。

您最后的操作将是删除名称 H。因此，对于两种情况，我们都可以得出结论

feature

和：

...--F--G--H---------M   <-- master
            \       /
             I--J--K

现在，...--F--G--H---------S <-- master \ I--J--K和其他Git命令 find 通过以分支名称开头的方式提交，该分支名称指向一个特定的 tip 像git log或M一样提交，然后向后工作。不能找到的提交也可能不存在。因此，大约一个月后，Git将清理并删除第二张图中无法找到的提交，让您：

这是南瓜合并与真正合并之间的最终区别：真正合并保留完整的历史记录，包括导致产生合并的单个提交。壁球合并会丢弃导致产生壁球合并的历史记录，只保留一个实现相同效果的提交-就像编写壁球合并代码的人通过坐下{ {1}}，将所有内容写为一个提交，然后提交。

Answer 2

是的，更改将与所产生的代码库相同。

与提交历史不同。它可能会影响某些日志输出，并且压扁路由将导致在删除功能分支后无法检查原始提交。

另一方面，no-ff路线将具有更详细的历史记录。

如果不久之后删除了源（功能）分支，--squash合并和--no-ff合并之间有什么区别吗？

2 个答案: