不断的合并问题，从发布分支到主分支，再回到开发分支。

Question

我们的合并策略出现了一些奇怪的问题。我们遵循了git flow分支策略，包括主分支、开发分支、功能分支和发布分支。唯一一件我们没有一直做的事情是将主分支合并回开发分支。

这一次，我们希望在发布后开始将主分支合并回开发分支，以解决我们的问题。所以我们从开发分支创建了一个发布分支，向主分支创建了一个PR（出现了冲突，我们解决了冲突）。在发布分支上进行了一个热修复，该热修复是从一个功能分支合并而来的（基于发布分支），并在获得批准后合并到主分支。然后我们将其合并回开发分支（只在热修复问题上出现了冲突）。

然后，为了尝试一些东西，我们从开发分支向主分支创建了一个PR，我认为这应该没有任何冲突，但是我们发现大约60-70%的文件都有冲突。

我们尝试了不同的合并策略，如rebase no fast-forward、squash commit、基本合并等等。但似乎没有什么用。

从最新的提交哈希来看，开发分支现在比主分支领先一次提交，这是应该的。问题可能是什么？我们应该如何解决这个问题？不同的合并策略应该不是问题吧？

- peuhse

---

提到主分支必须合并回开发分支，说明你的git工作流程出了问题。工作流程应该是从开发分支到主分支，而不是相反的。 - undefined

你是在进行真正的合并，还是使用“压缩”选项创建虚假的合并提交？“压缩合并”并不是真正的合并，如果再次合并会导致冲突。 - undefined

在Git Flow中，你必须将master分支合并回develop分支（或者至少将release分支合并回develop，这几乎是一样的）。在Git Flow中，你也不会将develop分支合并到master分支，而是使用一个中间的release分支。如果你在每次发布后不将master分支（或者至少是release分支）合并回develop分支，你将遇到这里描述的问题。 - undefined

@TTT，好的，可能我忘记了关于Git Flow的理论，但从逻辑上讲，如果我们将develop合并到release并成功，然后将release合并到master，很有可能也会成功。之后，所有位于develop中的提交已经在develop中了 - 不需要再次合并。日常例行合并只从develop合并到topic分支，只是为了与最新的更改保持一致，并避免将冲突合并到develop中。其他工作（develop -> release -> master）应该顺利进行。这是基于实践的，但我并不坚持这种方式。 - undefined

在你所描述的情况下，我同意，但并不总是在将release分支合并到master之前没有任何新的提交。（事实上，我认为这种情况很少见。）一旦release分支上有一个单独的错误修复，它必须回溯到develop分支，否则在后续的发布中可能会被撤销。 - undefined

Answer 1

通常在Git Flow中，将一个release分支合并到master时不会出现冲突。原因是release分支应始终与master完全同步，可能只有一些空的合并提交除外。请注意，当将release或master合并回develop时可能会出现合并冲突。希望这种情况很少见，但在同时开发两个不同分支并最终合并的正常过程中（例如在develop上进行功能开发和在release上进行错误修复），这种情况是可能的。

Git Flow的使用规则要求在任何时候将release分支合并到master时遵循以下规则：

release被合并到master使用的是常规合并方式，而不是rebase或squash。此外，Git-Flow强烈建议使用merge --no-ff来保留部署历史记录，许多PR工具默认使用--no-ff进行常规合并。

在将release合并到master后，您应该立即将release合并到develop，如Git Flow所述，或者您可以将master合并到develop。我更喜欢后者，这样master上的新合并提交将立即传递到develop，这意味着develop和下一个release分支在状态和提交方面都与master完全保持同步。如果您选择将release合并到develop，随着时间的推移，您将在master上积累多个空的合并提交，最终在未来进行热修复时，所有这些提交将一次性传递到develop。

对于一个“hotfix”分支，规则是类似的，但是在将“hotfix”合并到“master”之后，如果存在“release”分支，则应将“master”合并到“release”，如果没有待处理的发布分支，则应将其合并到“develop”。

如果始终遵循这些规则，在将“release”合并到“master”时将不可能发生冲突。

关于您的具体情况的其他说明：

我们一直没有做的一件事是将主分支合并回开发分支。

如上所述的规则#2，这是必需的。如果您跳过此步骤，则在“release”分支上的任何新错误修复可能不会传回“develop”，这意味着下一个“release”分支可能会缺少这些错误修复。如果您从“release”而不是“master”部署，您实际上可能会撤销下一个发布中的这些错误修复。此外，这将为下次将“release”合并到“master”打开冲突的大门，而通常情况下是不可能的。

我们尝试过不同的合并策略，如rebase no fast-forward、squash commit、基本合并等等。但似乎都没有关系。

关于合并策略的类似规则与上述规则＃1有关，这适用于Git的一般情况，而不仅仅是Git Flow：

Git合并的经验法则：当将分支source合并到分支target时，如果source是一个长期存在的共享分支，则不应该重写该分支。

这意味着在执行"Git Flow"合并，如将release合并到master，将master合并到develop等操作时，永远不要使用rebase或squash，这两种方法都会重写分支上的提交。应始终使用常规合并，在Git Flow中，建议即使可以进行快进合并，也要使用--no-ff。如果重写共享分支，将导致未来合并中的不必要冲突。

注意，在将“feature”或“topic”分支合并到共享分支时，可以使用rebase和squash，因为这些分支不是共享的，一旦合并到共享分支后，它们可以被删除。特别是在rebase时，如果有多个提交，Git Flow建议在rebase之后仍然强制进行合并提交（有时称为“半线性合并”），以保留哪些提交是特性的历史记录。而squash和单提交特性没有额外的历史记录需要保留，因此不需要额外的合并提交。

然后，为了尝试一下，我们从开发分支创建了一个PR到主分支，我认为这应该没有冲突，但是我们发现大约60-70%的文件存在冲突。

只要开始遵循上述两个Git Flow规则，这个问题就会消失。顺便说一下，Git Flow没有记录过将“develop”合并到“master”的情况；相反，你应该有一个中间的“release”分支。（但是如果你的发布分支在从“develop”创建后没有任何新的提交，这种情况是可能发生的。）

- TTT