发布分支上的Git流混乱

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

在这个场景中，我通过分别打开master和dev的PR合并了我的发布分支。我将PRs与使用

git merge --squash

指挥部。在合并结束时，我有两个不同的提交ID

主人有D1234 开发人员拥有C4567

我的困惑从这里开始。如果master和dev没有相同的提交散列，在发布分支的下一个PR-to-master中，我将在PR中看到C4567。我必须合并一个空的提交，没有差异。我哪里出错了？合并后，如何为master和dev获得相同的头

解决方案：挤压合并不是合并 合并后，如何为master和dev获得相同的头

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

git中的分支指向提交；该提交指向历史中的其他提交。每个提交都由唯一的散列标识；如果两个不同的提交具有相同的散列，那么所有内容都将被严重破坏。该散列既包括存储库的内容，也包括提交的所有元数据，包括它的父级

因此，如果两个不同的分支指向同一个散列，那么这些分支是相同的——不仅在当前内容上相同，而且在整个历史上都相同

实现这一点的唯一方法是始终在任何地方使用“快进”合并，以便所有分支实际上都只是一行提交中的指针。实际上，这意味着很多事情都需要重定基调——例如，每个修补程序都可能需要重定整个develope的基调，然后将所有打开的特性分支重定基调到新的develope上

要避免这种情况，需要做很多工作，也有很多事情可能会出错：

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

Git非常聪明，即使您合并了两个不相关的提交（记住：挤压合并会丢弃特性分支上的所有历史记录），也不需要进行任何实际更改。这就是为你解决问题的方法

---

另一种解决方案，如注释中所指出的，是首先不要将功能合并到两个位置。将发行版合并到母版，然后将母版合并到开发版。

您的图表是错误的。挤压合并不是合并。它导致一个新的提交凭空出现，没有关于如何或为什么这样做的记录。如果对

master

执行挤压合并，对

dev

执行挤压合并，则master和dev是两个完全独立的提交，彼此无关，也与功能分支无关。因此，从特征分支末端指向

master

和

dev

末端的箭头为假，应删除

如果你想在这些东西之间建立某种关系，至少要使用真正的合并。不要走捷径。按常规方法执行此操作：PR到dev，merge到dev，然后查看如何将其（dev上的merge commit）放到master上

---

发布分支（这似乎是您要问的）与dev的正常分支类似，除了（1）它阻止所有功能被合并到dev中，以及（2）正如您正确地说的，这里的目标是合并到master中，当然我们还必须合并回dev。您可能希望看到原始文档，这比您引用的atlassian页面更简单、更清晰。

我合并了我的发布分支，通过此流程分别向master和dev打开PR，您应该只向dev打开PR（可以选择与squash合并），然后稍后将dev合并为release，然后再向master（不带squash）。为什么是2个PRs？我支持不将修补程序合并到master和develop的建议。我个人认为，在修补程序的情况下，与master的重新同步应该来自master。从理论上讲，除了热修复更改之外，master中不应该有任何不在开发中的东西（除了不同的配置之类的东西——对于那些您只需要小心的配置）。对我来说，这是一次精神检查。若不能合并master来很好地开发，那个么根据本文，我们应该将发布版本合并到dev和master。据我所知。你的意思和那份文件不一样吗？除了像你所说的压榨东西之外，还有发行分支的情况吗？但是该文档没有提到打开两个PRs，使用挤压合并，或者你做过的任何事情。在没有打开两个PRs的情况下，如何将发布版与dev和master合并？PRs不是git的特性。Git流是关于Git的。您如何管理PRs取决于您；不同的开发公司有不同的政策来处理这个问题。好的，谢谢。我现在明白了。挤压并不像你说的那样合并。我们应该使用--no--ff来跟踪git历史。它的缺点是，并没有ff创建合并提交，它使master领先于dev，反之亦然。另一方面，我们可以将ff用于git历史的单行，但这会使跟踪历史变得更加困难。如果目标有更新的提交，我们还必须重新设置基础。再次感谢