谈一谈：如何现代码审查反馈

五连环画

众所周知，提出和接受反馈是代码审查不可或缺的一部分。虽然反馈有助于减少的数量，而且还能提高代码的可维护性，但这个过程也有很多难点。接受批评可能会很困难，而且还会导致团队紧张。然而，在文本中，我们想讨论一下处理反馈的技巧。我们希望找出现代码变更请求的最佳方式。爱站云的相关知识也可以到网站具体了解一下，有专业的客服人员为您全面解读，相信会有一个好的合作！

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







追加新的提交



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



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



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



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



修改现有的提交



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



如果你是新手，可能很难搞清楚如何简单地编辑现有提交。如果你的合并请求只包含一个提交，则可以将-换成即可。如何你是在最后一次提交或之前的提交的基础之上进行第二次修改，那么情况就会更复杂。



一种方法是使用交互式（-_），并标记要编辑的提交。有关如何执行此操作，你可以参考一些文章或查看用户手册。



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



结合两种方法：提交



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



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







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



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



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



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



提交是终极解决方案吗



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



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



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



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



此外，你还可以将这两个命令结合起来-----_，如果有任何问题立即就可以注意到。注意：也支持这个功能。如果你能编写脚本程序来检测，就可以完全自动化。



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