软件开发中的一种常见情况是代码检查其他人的代码。执行此操作的常用工具是打开请求请求。
我的问题是，当在审查中发现问题时，是否应进行更改
- 分开提交（新提交）
- 还是应该修改现有的提交（假设没有人从您先前的提交中分支出来，因为从共享分支重写历史记录是个坏消息）。
对于第一种情况，尽管它会在提交历史记录中增加一些噪音，但是很容易跟踪增量更改。第二种选择具有相反的优点和缺点。
14
您对提交说“噪音”，但我读到的是准确的历史记录。为什么要掩盖提交历史中真正发生的事情？代码审查是代码审查，无需将其描绘为其他内容。在这种情况下，我的投票将投给单独的提交，而不是重新定基。
—
托马斯·斯金格2015年
通常我都做。分别发布每个提交，然后在审阅完成后重新设置基础并合并。即使在删除或替换了这些提交之后，GitHub仍在讨论关于拉取请求的问题，因此重新部署基准不会造成重大损失。您将两全其美。
—
Ajedi32
我对自己是否犯了某些东西（后来以某种方式确定崩溃了系统）感到mixed贬不一。如果我很快发现自己的缺点，这些承诺就是我想从历史中回退的承诺。但是它们只是零碎的东西，它们并不需要花那么多钱，因此，最安全，最具成本效益和一贯性的工作（就像在理论中一样）可能总是分开提交，让汽车残骸沉没在沟渠中，每个人都可以现在看到，直到永远。....并且您可以在每个有缺陷的分支上标记一条明确的消息，以使其不建立在该分支上，因此没有共享分支。
—
罗伯特·布里斯托
您能解释什么是“变基”以及何时需要它吗？
—
Kilian Foth，2015年