在将代码提交到主干之前，复查代码的最佳方法是什么？（SVN）

在将代码提交到SVN干线之前，检查代码的最佳方法是什么？我想到的一个想法是让开发人员将其代码提交到分支，然后在将分支修订合并到主干的同时查看他的代码。这是一个好习惯吗？如果不是，在将代码提交到主干之前还可以做些什么来检查代码？

虽然有两种流派-您提出的建议或“提交之前进行审查”。大多数差异可以看作是负面和/或正面。-例如，没有跟踪由审阅引起的更改-您想将这些视为离散提交，还是只对最终工作感兴趣？

提交之前进行审核-无需分支（尽管可以根据需要完成分支），必须使审核者可以访问工作文件夹。可以在审核期间和审核后更改代码，而无需跟踪。由审核引起的更正不会出现在资源库中。

提交后审阅（在分支上）-需要为每个审阅旋转一个分支（尽管它可能已经在工作流中了）。如果没有跟踪更改，则无法更改提交审核的代码。有人必须合并已审核的分支，并跟踪已审核的内容和未审核的内容。

这在很大程度上取决于团队的文化和经验。您信任什么模型，它的主要目的是什么？我个人更喜欢提交后进行审阅，因为它允许跟踪审阅结果。现在，我们使用Git和Gerrit，因为它们在两个选项之间提供了很好的平衡。

1. 提交之前，请运行“ svn diff”以生成补丁文件。
2. 将补丁文件发送给审阅者，审阅者将其应用于主干的干净副本。
3. 审阅者使用选择的差异查看器查看更改。
4. Reviewer执行构建并运行测试。
5. 如果一切顺利，请告诉开发人员他们可以检查其更改。如果
   有问题，开发人员将返回步骤1。

有理想的世界，然后是真实的世界。

在理想的世界中，所有代码都经过了测试，因此您可以确保所有签入的内容都可以正常工作，或者您将知道它已损坏，因为它无法通过一个或多个测试。另外，没有经验的人将与经验丰富的人配对，因此代码审查是即时完成的（您可以随行提交）。

在现实世界中，情况有所不同。企业希望现在就可以实现这种改变并且会以完美的表情告诉您，是的，您将有时间清理代码并在以后添加测试用例。您可能没有时间对所有内容进行代码审查，并且测试所覆盖的代码百分比不断下降。代码审查的主要原因是让初级开发人员从资深开发人员那里学习（如果有时间的话），方法是让经验丰富的人员查看更改并提出“更好的处理方式（TM）”。您将拥有高级开发人员，他们只是提交未经审查的代码。只为进行代码审查而分支，然后合并是非常浪费时间的。解决此问题的一种方法是宣布每周一次的2小时（或大约每周一次）团队会议，在此会议上您可以选择一两个人最近所做的近期更改，并在短时间内通知其作者进行“演示”。他们的方法是在投影机或其他设备上一起查看代码。这可能会引起一些有趣的讨论（通常会引起很多话题），但通常会提高每个人对如何正确执行操作的理解。再加上可能不得不展示您的代码的压力使某些人做得更好；-)

或者，您可能很幸运，并且可以在不那么忙碌的现实环境中工作，程序员实际上是为他们的工作而不是被滥用而受到赞赏，并且有时间做正确的事。在这种情况下，我的答案是：尝试此处答案中建议的一些不同方法，并查看哪种方法适合您的团队以及您的工作方式。

根据我在上一份工作的预提交审核中使用它们的经验，分支应该可以正常运行。

_{请注意，那时，我们仅对生产发行候选代码的关键补丁使用提交前检查，因此没有太多分支（例行更改通过提交后检查传递）。}

由于您似乎将对所有更改使用预提交审核，因此您可能需要管理大量分支。如果您希望开发人员平均每周进行一次“可审查的”更改，那么最终每个团队中的每个开发人员每年将拥有约50个分支。如果您使用的工作量较小，例如需要1、2、3 ...天的工作，则将50乘以2、3、5...。

如果您想要最好的方法，以下是一些其他要考虑的因素。

1.处理延迟审核阻止其他团队成员需要的代码的情况

建立，监视和解决与代码审阅期限有关的冲突。根据我对过去一个项目中进行的例行变更的提交前审查的回顾，合理的截止日期大约为3天，而开始担心的是提交后超过1天未完成审查。

_{为了进行比较，在提交后的评论中，这些要求要宽松得多（我使用2周的截止日期，并在1周后开始担心）-但是由于您以提交前的评论为目标，所以这可能并不有趣。}

2.提交审核代码时合并冲突

如果在代码等待审阅时其他人进行的冲突更改阻止了提交审阅代码的操作，该怎么办？

要考虑的几个选择是

• 回滚到开始并要求开发人员重新实施并重新审查更改。
  在这种情况下，您可能需要解决对团队士气的负面影响（可能！）。
• 将合并的责任转移给其他团队成员（“合并主”），
  在这种情况下，您还需要确定合并本身是否应经过提交前的审查-如果是，那么在发生以下情况时应采取的措施合并又遇到了另一个冲突。
• 忽略在合并阶段对审阅的代码所做的更改
  对于这种情况，您可能需要解决对团队士气的负面影响，这与所提交的代码与所审阅的代码不同的事实有关。
• 发明一种避免冲突的
  方法直截了当的方法是一次只允许一个开发人员修改特定的文件集-尽管这不会保护您免受那些不会直接修改文件的更改的影响，而是会通过内部API更改来影响它们。您可能还会发现，这种“悲观锁定”使系统范围的更改和深度重构变得相当麻烦。

_{为了进行比较，提交后的审阅中不会出现此类问题（因为它们处理的代码已按定义合并）-但是由于您以提交前的审阅为目标，所以这可能并不有趣。}

3.加载等待审核的开发人员

为提交评论的开发人员应该切换到新任务还是做其他事情（例如追逐评论者），建立明确的政策。

_{为了进行比较，提交后的审核几乎不需要明确的政策（因为在提交代码后很自然地进行下一个任务，并且考虑到审核截止时间是一两周）-但是由于您以提交前的审核为目标，因此没意思。}

任何需要审查的开发项目都必须位于单独的分支中。因此，该分支应该在检查时间之前已经存在。然后，该步骤将需要是：

1. 评论
2. 修改（可能）
3. 循环回到评论（可能）
4. 合并到行李箱

合并是困难的一点。分支保持独立的时间越长，将其合并回主干的难度就越大。（这也可能很难测试。）

交叉合并是一种可能的解决方案。在合并到主干中之前（步骤4，或更早，例如在步骤3或步骤1之前），将主干合并到分支中。开发人员可以做到并对其进行测试。然后，分支赶上了主干，将其合并到主干变得更加容易。最好由您或负责树干的任何人将其合并到树干中。

有些人尝试重新设置基准，而不是交叉合并。有人认为改组是邪恶的。那是另一场辩论。