我是否应该修改合并提交以使测试通过？

Question

最近，我偶然发现了这的文章。它提到：

此外，每个提交都应该成功地编译和运行所有测试，并且应该避免在将来的提交中修复任何已知的bug。

这让我思考。有时，在我将develop合并到feature分支之后，即使我没有冲突，我仍然需要调整一些代码，所以它可以处理我的更改并通过所有测试。

我的问题是，最好的方法是什么？

• 修改合并提交
• 或者创建一个全新的提交

我不觉得在合并提交中偷偷增加代码是个好主意，但是如果我不这样做，这个提交将有“已知的错误”，我应该避免，对吗？

我很想听听一些实际/现实的争论，它对git-bisect的工作有什么影响？(我还没有使用它，但我知道它存在，总有一天会派上用场)

Answer 1

正如其他人所指出的，处理此问题的理想方法是在合并之前将补丁提交到开发/特性分支中。例如：

...--o---------------------M   <-- master
      \                   /
       o--o--o--o--o--o--*   <-- develop

其中提交*是使合并顺利进行并生成工作合并提交M所需的修复。

在实践中，无论是哪种方式，往往都没什么大不了的。如果commit M会失败现有的测试，CI系统将执行这个最佳实践，而且一切都会很好--但是如果M中实际失败的东西是新的，这是以前从未观察到的，而且是意外的呢？CI系统不会注意到，你也不会注意到，除非你提交了一些X

                                o--o--X   <-- topic
                               /
...--o------------------M--o--o--...-o   <-- master
      \                /
       o--o--o--o--o--o

现在你发现了，哎呀，我们应该做个测试的。所以现在您可以添加测试，但是不能返回并更改M，也不能更改它的任何后代。解决这一问题的理想方法是在新的测试和修复分支上检查bug发生的第一个点，编写测试和修复，并将其保存为方便的分支，例如：

                                o--o--X   <-- topic
                               /
...--o------------------M--o--o--...-o   <-- master
      \                /
       o--o--o--o--o--o
                    \
                     F1--F2   <-- test-and-fix

Commit F1有新的测试(失败)，F2修复了它。现在，您可以使用git checkout master; git merge test-and-fix和git checkout topic; git merge test-and-fix将修复引入master和每个主题/开发分支。

(实际上，绘制结果的图形会很痛苦。)

在实践中，很多人只是在master的末尾挑选一个修复程序。

                                o--o--X--F12'   <-- topic
                               /
...--o------------------M--o--o--...-o-------F12   <-- master
      \                /              \      /
       o--o--o--o--o--o                F1--F2   <-- test-and-fix

其中，F12'是组合/合并F12的主要选择，这通常是可以的。但是尽早修复，在bug最初创建的时候，至少在理论上是更好的。有关此问题的更多信息，请参见陈钟泰的博客。