git - 如果源(功能)分支不久后被删除，那么 --squash merge 和 --no-ff merge 之间有区别吗？

Question

如果源(功能)分支随后立即被删除，那么关于存储库的最终状态，--squash merge 和 --no-ff merge 之间是否有区别？

--no-ff merge 提交将包含与挤压 merge 提交相同的更改，对吗？

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 上的新提交 - 我们将将此提交称为 M 进行 merge ，即使下一个提交也是如此可用字母是 L — 看起来像:

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

(或类似的)。新提交M的第一个父级是现有提交H:是提示的提交掌握之前。新提交M的第二父级是现有提交K:曾经是，现在仍然是feature<的尖端.

(如果您的起始图表类似于第二个示例，其中 feature 与 master 共享的第一个提交是 G 而不是 H，--no-ff 参数不是必需的。Git 必须执行真正的 merge ，所以它会。如果您的起始图看起来像第一个示例，--no-ff 强制 Git 进行真正的 merge ，即使公共(public)起点提交已经是 master 的提示。)

---

如果您运行 git merge --squash 而不是 git merge --no-ff，您会得到以下结果:

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

我们可以在其中调用新提交 S 进行挤压，而不是 M 进行 merge 。就内容而言，提交S与M完全相同。主要区别在于提交 S 只有一个父级:提交 H。

您的最终操作将是删除名称功能。所以让我们针对这两种情况画出它

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

和:

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

现在，git log 和其他 Git 命令 find 通过从分支名称开始提交，分支名称指向一个特定的提示 像 M 或 S 一样提交，然后向后工作。无法找到的提交也可能不存在。因此，大约一个月后，Git 将清理并删除第二个图中找不到的提交，留下:

...--F--G--H---------S   <-- master

这是挤压 merge 和真正 merge 之间的最终区别:真正的 merge 保留完整的历史记录，包括导致生成 merge 的各个提交。挤压 merge 会丢弃导致生成挤压 merge 的历史记录，只保留实现相同效果的单个提交 - 就好像编写挤压 merge 代码的人通过坐下来使用<中的代码来完成它一样code>H，将所有内容编写为单个提交，然后提交。