Git Flow 混淆：关于 Release 分支

Question

Git Flow 混淆：关于 Release 分支

3

我正在尝试理解Git Flow中的一件事情。假设我们有以下分支树：

在这种情况下，我通过向主分支和开发分支分别打开PR来合并我的发布分支。我使用了以下方法合并PR：

git merge --squash

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

主分支为D1234，开发分支为C4567

我的困惑从这里开始。如果主分支和开发分支没有相同的提交哈希，那么在从发布分支到主分支的下一个PR中，我会看到C4567。我必须将一个没有差异的空提交合并。我犯了什么错误？如何在合并后获得相同的HEAD作为主分支和开发分支？

解决方案: 拉取请求压缩合并不是真正的合并

- Berkin

1

我通过向主分支和开发分支分别打开PR来合并我的发布分支。使用这种流程，您应该只向dev打开PR（可选择使用squash合并），然后稍后将dev合并到release，然后再合并到master（不使用squash）。为什么要开两个PR呢？ - Gaël J

2个回答

0

如何在合并后使主分支和开发分支具有相同的HEAD？

你不能。嗯，技术上你可以，但你可能不想这样做。

Git中的一个分支指向一个提交；该提交指向其他提交，回溯整个历史记录。每个提交都由唯一的哈希标识；如果两个不同的提交具有相同的哈希，则所有内容都将被破坏。该哈希覆盖了存储库的所有内容以及提交的所有元数据，包括其父项。

因此，如果两个不同的分支指向相同的哈希，则这些分支是相同的-不仅在其当前内容上相同，而且在其整个历史记录上也相同。

唯一的方法是始终在所有地方使用“快进”合并，以便所有分支实际上只是单行提交中的指针。在实践中，这意味着需要经常进行变基-例如，每个热修复都可能需要对整个开发分支进行变基，然后将所有打开的功能分支重新基于新的开发分支。

这是很多工作，很多事情可能会出错，为了避免这种情况：

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

Git 足够聪明，能够识别出不需要进行实际更改，即使你合并了两个不相关的提交（记住：压缩合并会丢弃特性分支上的所有历史记录）。这就是它为你解决问题的方式。

另一个解决方案，正如评论中指出的那样，是首先不要将特性合并到两个地方。将发布合并到主分支，然后将主分支合并到开发分支。

- IMSoP

我赞同不将热修复合并到主分支和开发分支的建议。个人认为，像热修复这样的重新同步应该来自于主分支。理论上除了热修复更改外，主分支中不应该有任何不在开发分支中的内容（减去像不同配置之类的东西-对于这些，你只需要小心）。对我来说，这是一个理智的检查。如果主分支无法顺利地合并到开发分支，则说明存在严重问题。 - slebetman

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- matt · Accepted Answer

你的图表是错误的。Squash merge 不是一种合并方式。它会导致一个新的提交出现在空中，没有任何记录说明如何或为什么这样做。如果你对 master 和 dev 进行 squash merge，master 和 dev 就是两个完全独立的提交，彼此之间和 feature 分支没有关系。因此，从 feature 分支末尾指向 master 和 dev 的箭头是错误的，应该删除。

如果你希望这些事物之间存在某种关系，至少要使用真正的合并。不要走捷径。按照正常方式操作：向 dev 发起 PR，将其合并到 dev，然后再考虑将其（即在 dev 上的合并提交）合并到 master。

一个发布分支（这似乎是你在问的）类似于从dev分支中普通分支，但是（1）它停止所有功能合并到dev，（2）正如你所说，目标是合并到主分支，当然我们也必须合并回dev。你可能想看看原始文档https://nvie.com/posts/a-successful-git-branching-model/，它比你引用的atlassian页面更简单、更清晰。