为什么我最终会产生一堆合并提交？

Question

我们与发布分支，开发分支和发行分支合作。

我们的问题分支仅包含该问题的提交。

一旦开发人员完成问题并提交拉取请求，他们就会合并到开发人员，以便它保持更新。

在测试了各个发行分支之后，这些分支将被逐一合并到发行版中。

此时，我们的变更日志将在release分支上进行更新，然后将其合并回dev中。

最终结果是我在dev中显示了一堆合并提交，因此看起来dev是在发布之前的一堆提交，实际上应该全部捕获。例如：

在这一点上，如果我将开发人员合并回到发行版中，则表明它们不再彼此领先/落后，但是实际上没有引入任何新代码。这只是一堆合并提交。

我们在做错什么导致这种情况？我们将非常感谢您提供有关如何改进此过程并避免这些问题的任何信息。谢谢！

Answer 1

您没有做任何“错误”的事情； git只是记录您告诉它的内容：

• git中的commit是一个不可变的对象，用于指定其内容以及元数据。至关重要的是，这包括提交父级的哈希（提交ID）。
• 将两个分支合并在一起时，git会创建一个提交，其内容是合并的结果，并且其元数据包括两个父提交的ID。
• 如果您以不同的顺序甚至在不同的时间合并相同的更改，则生成的 content 可能是相同的，但是 metadata 会有所不同。
• 当git比较两个分支时，它首先查看一个分支的历史中存在哪个提交（具有唯一的哈希），而另一个分支的历史中不存在。然后，它查看在那些提交中对内容所做的更改，并尝试重新应用它。

因此git非常正确地告诉您，将内容合并到发布分支中时记录的提交在dev上不存在，但是由于它们没有更改任何内容，因此可以在不更改任何内容的情况下重新应用它们。

在某些情况下，您可以先进行重新设置然后进行“快速合并”，以避免创建合并提交（这样，历史记录看起来好像所有提交都是直接在一个分支上进行的，并且没有记录合并本身）。但是，这会使情况变得更糟，因为如果您基于release分支，将创建一组在dev中不存在的新提交-您无法“移动” git commit，只复制它并获得新的哈希。

因此，如果您的流程从质量检查的角度来看可行，那么您可能必须忍受这些额外的合并提交。人们写了很多不同的合并策略，但是您可能要考虑是否存在更广泛的问题。