最近，我偶然发现了本文。它提到：
此外，每个提交都应成功编译和运行所有测试，并应避免使用将来将在未来提交中修复的任何已知错误。
这让我思考。有时，在将develop合并到feature分支中后，即使我没有冲突，我仍然必须调整一些代码，因此它可以与我的更改一起使用，并且所有测试通过。
我的问题是，这样做的优选方法是什么？
- 修改合并提交
- 或创建一个全新的提交
我觉得在Merge提交中偷偷漫步代码不是一个好主意，但是如果我不这样做，此提案将具有我应该避免的"已知错误"，对吗？
我很想听听一些实用/现实的论点，它如何影响与git-bisect一起工作？(我还没有使用过，但是我知道它存在并且有一天可能会方便(
正如其他人所指出的，处理此问题的理想方法是在合并之前将修复程序提交为开发/功能分支。例如：
...--o---------------------M <-- master
/
o--o--o--o--o--o--* <-- develop
commit *是使合并顺利进行并产生工作合并cod M所需的解决方案。
实际上，无论哪种方式，通常都不是那么大。如果提交M将失败现有测试，则CI系统将执行此最佳实践，一切都很好，但是如果M中实际失败的事物是 new ，那是从未观察到的失败意外？CI系统不会注意到，您也不会注意到，直到您到达一些提交X：
o--o--X <-- topic
/
...--o------------------M--o--o--...-o <-- master
/
o--o--o--o--o--o
现在，您发现，糟糕，我们应该对此进行测试。因此，现在您可以添加测试，但是您不能返回并更改M，也不能添加任何后代。解决此问题的理想方法是查看错误在新的测试和修复分支上出现该错误的第一个点，编写测试和修复程序，并将其保留为方便的分支，例如：
o--o--X <-- topic
/
...--o------------------M--o--o--...-o <-- master
/
o--o--o--o--o--o
F1--F2 <-- test-and-fix
提交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的樱桃摘要，这通常可以正常工作。但是，在最初创建错误的时候进行修复至少在理论上更好。有关此的更多信息，请参见Raymond Chen的博客。