Git 为什么我最终会有一堆合并提交？

我们使用发布分支、开发分支和发布分支

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

一旦开发人员完成了一个问题并提交了一个请求，他们就会合并到dev中，以保持更新

在测试各个问题分支之后，这些分支将逐个合并到发布中

此时，我们的变更日志将在发布分支上更新，然后将其合并回dev

最终的结果是，我在dev中出现了一堆合并提交，所以看起来dev在发布之前是一堆提交，而实际上应该是所有提交。例如：

在这一点上，如果我将dev合并回发行版中，这表明它们不再相互领先/落后，但实际上并没有引入新代码。这只是一堆合并提交

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

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

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

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

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

因此，如果您的流程是从QA的角度工作的，那么您可能不得不接受这些额外的合并提交。有很多不同的合并策略，人们可能会考虑，如果有更大的问题，但是，