代码审查反馈提交修复时，是否应该压缩提交？

作者 | Michael Müller
译者 | 弯月
出品 | CSDN（ID：CSDNnews）

提出和接受反馈是代码审查不可或缺的一部分。虽然反馈有助于减少 bug 的数量，而且还能提高代码的可维护性，但这个过程也有很多难点。接受批评可能会很困难，而且还会导致团队紧张。然而，在文本中，我们想讨论一下处理反馈的技巧。我们希望找出实现代码变更请求的最佳方式。

在提出合并请求后，被要求修改代码时，你有两种选择。这两种方法都有各自的优缺点。

追加新的提交

追加新的提交非常简单快捷。因为你可以根据每个变更请求创建一个提交，这样审查者就可以了解到你针对他们提出的反馈做了怎样的处理。这种方法的缺点是，git 历史记录不太整洁。

整洁的 git 历史记录不仅仅关系到拥有更好的 git 日志输出。随着时间的推移，项目会不断发展，变得越来越复杂，整洁的 git 历史记录有助于我们查明导致某个 bug 的原因。我们会使用 git bisect 来找出哪次变更破坏了代码（更多信息，请参阅 git 用户手册或 git bisect）。

只有当你确信每个提交都能正常工作时，这种方法才有效。因此，包含有可能破坏代码的提交会非常讨人厌。最终你有可能得到错误的结果，或者你必须跳过某些提交。

避免这个问题的一种方法是在合并代码时，压缩提交。对于只有一个初始提交的小型合并请求来说，这种方法尤其奏效。当代码变更越来越大时，你可以将它们分组成多个小型的逻辑提交。这不仅可以提高 git bisect 结果的准确度，而且还可以加快代码审查。但是，在合并期间压缩提交会降低生产率，因为所有代码都会变成一个巨大的提交。

修改现有的提交

为了避免上述缺点，你可以在原始提交中处理反馈意见。这种方法需要更多的时间，而且需要熟练掌握 git。

如果你是 git 新手，可能很难搞清楚如何简单地编辑现有提交。如果你的合并请求只包含一个提交，则可以将 git commit -m “…” 换成 git commit–amend 即可。如何你是在最后一次提交或之前的提交的基础之上进行第二次修改，那么情况就会更复杂。
一种方法是使用交互式 rebase（git rebase -i base_branch），并标记要编辑的提交。有关如何执行此操作，你可以参考一些文章或查看 git 用户手册。

虽然这种方法非常强大，而且还可以通过各种方式修改 git 历史记录，但这并不是最快的修复提交的方法。

结合两种方法：fixup 提交

git有一个鲜为人知的功能，你可以结合以上两种方法。你可以创建新的提交来修复代码，同时还能得到一个整洁的 git 历史记录。我指的就是 fixup。这种提交带有特殊的提交消息，告诉 git rebase 将代码变更分别合并到各自的原始提交中。如果你从未听说过这个命令，也不用感到惊讶。git 手册并没有提到这个命令，而且其他文档也未能很好地解释这个特性。下面，我们就来看看如何使用这个命令。

在这个示例中，我们将设法修复如下 git 历史记录（git log --oneline）：

29a0f49 (HEAD -> feature-branch) good commit54a0517 broken commit00eecd3 (master) initial commit

假设我们需要修复的提交名为“broken commit”。第一步，像往常一样修改代码，并保存到预发布环境（gitadd -u -p）。在提交这个变更时，我们不写提交消息，而是通过 git commit --fixup54a0517 告诉 git 创建修复提交。新建的 git 提交如下所示：


c1e7149 (HEAD -> feature-branch) fixup! broken commit
29a0f49 good commit
54a0517 broken commit
00eecd3 (master) initial commit

为了获得整洁的 git 历史记录，我们需要执行 git rebase -i --autosquash，将变更后的代码重新合并到各自的原始提交。git 会显示执行 rebase 命令的经过。除非你想手动修改历史记录的其他部分（例如提交消息），否则只需关闭编辑器即可。查看 git log --oneline，你就会注意到完全没有 fixup 提交的痕迹：

8f15489 (HEAD -> feature-branch) good commit
079dc70 broken commit
00eecd3 (master) initial commit

git历史记录与第一个完全相同，只不过哈希由于 rebase 而改变了。

上述只是一个非常基本的示例，展示了如何使用 fixup 提交。在实际的工作中，你可能会有多个 fixup 提交，甚至可能都是针对同一个原始提交。

fixup 提交是终极解决方案吗？

fixup 提交是整合反馈的好方法，但这种也有其局限性。如果提交之间相互依赖，或编辑相同的代码区域，则 git 可能无法自动将修复重新合并到已有的提交中。

最终你不得不再次使用交互式rebase 一步步执行 git 历史记录。不过，根据我自己的经验，很多时候使用 fixup 提交都没问题。不过，这就需要保证你们的代码都是很小的原子提交，而且你需要按照特定的顺序进行操作，比如移动代码块，只有这样 git 才能轻松地重新定位原始提交。

另一个可能出现的问题是，一不小心创建有可能破坏代码的提交。如果将变更 rebase 到了错误的提交，虽然 rebase 的运行会成功，但生成的代码可能是错误的，例如调用在未来的提交中才会定义的函数。

幸运的是，git 提供了这个问题的解决方案。我们可以告诉 git rebase 在每次提交时执行某个命令，如果遇到非零退出代码，则停止执行命令。这样我们就可以在提交过程中编译代码或运行测试。如果你想在每次提交时运行 make test，则可以尝试如下命令：git rebase --exec"make test" base_branch。

此外，你还可以将这两个命令结合起来 gitrebase -i --autosquash --exec “make test” base_branch，如果有任何问题立即就可以注意到。注意：git bisect 也支持这个功能。如果你能编写脚本/程序来检测 bug，就可以完全自动化 bisect。

fixup 提交的工作流程仍有一个小麻烦。你仍然需要手工查找提交的哈希或引用，并提供给 git commit --fixup，这多少有点麻烦。有很多包装器可以解决此类问题，例如git-fixup、git-autofixup 或 git-absorb。

参考链接：

https://mergeboard.com/blog/3-code-review-feedback-fixup/