发布分支上的 Git 流程混乱 解决方案：SQUASH MERGE 不是合并

如何解决发布分支上的 Git 流程混乱 解决方案：SQUASH MERGE 不是合并

我试图理解 git flow 中的一件事。假设我们有这样的分支树

在这种情况下，我通过分别向 master 和 dev 打开 PR 来合并我的发布分支。我将 PR 与 using 合并

git merge --squash

命令。在合并结束时，我有两个不同的提交 ID

主人有D1234 开发者有 C4567

我的困惑从这里开始。如果 master 和 dev 没有相同的提交哈希，在下一个从发布分支到 master 的 PR 中，我将在 PR 中看到 C4567。我不得不合并一个没有差异的空提交。我在哪里做错了？合并后如何为 master 和 dev 获取相同的 HEAD？

解决方案：SQUASH MERGE 不是合并

解决方法

你的图表是错误的。壁球合并不是合并。它会导致一个新的提交凭空出现，没有记录如何或为什么。如果您对 master 进行壁球合并，对 dev 进行壁球合并，则 master 和 dev 是两个完全独立的提交，彼此无关且与功能分支无关。所以从特征分支的末端指向master和dev末端的箭头是假的，应该删除。

如果您希望这些事物之间存在某种关系，至少使用真正的合并。并且不要走捷径。以正常方式执行此操作：PR 到 dev，合并到 dev，然后查看如何将其（dev 上的合并提交）提交到 master 上。

发布分支（这似乎是您要问的）就像 dev 的一个普通分支，除了（1）它阻止所有功能合并到 dev 中，以及（2）正如您所说的那样，目标这里是合并到master，当然我们也必须合并回dev。您可能想要查看原始文档 https://nvie.com/posts/a-successful-git-branching-model/，它比您引用的 Atlassian 页面简单明了得多。

,

如何在合并后为 master 和 dev 获得相同的 HEAD？

你不能。好吧，技术上你可以，但你可能不想。

git 中的一个分支指向一个提交；该提交指向其他提交，回溯历史。这些提交中的每一个都由唯一的哈希标识；如果两个不同的提交具有相同的哈希值，那么一切都会被严重破坏。该哈希既涵盖存储库的内容，也涵盖提交的所有元数据，包括它拥有的父项。

因此，如果两个不同的分支指向同一个散列，则这些分支是相同的——不仅在当前内容上相同，而且在整个历史记录中也相同。

发生这种情况的唯一方法是始终在任何地方使用“快进”合并，这样您的所有分支实际上只是一行提交中的指针。在实践中，这意味着要重新构建很多东西 - 例如，每个修补程序都可能需要重新构建整个开发，然后将所有开放的功能分支重新构建到新的开发上。

要避免这种情况，需要做大量工作，而且可能会出现很多问题：

我必须合并一个没有差异的空提交。

Git 足够聪明，可以识别出不需要实际更改，即使您合并了两个不相关的提交（请记住：壁球合并会丢弃功能分支上的所有历史记录）。这就是为您解决问题。

另一种解决方案，正如评论中所指出的，首先不要将功能合并到两个地方。合并release到master，再合并master到develop。