在提交之前跟踪和实施同行评审的最佳方式

Question

我想知道人们用什么机制来执行和跟踪提交给SVN的同行评审。

对于每次提交，我希望能够跟踪人们是否进行了同行评审（我不确定是否强制执行他们无法提交的规则是一个好主意，我的直觉是它不应该是强制执行，因为在没有同行评审的情况下提交可能有正当理由），但应该能够跟踪未经审核的提交，以便在发布之前我们可以查看所有这些提交。

Answer 1

您可以要求每个开发人员以[REV：XYZ]等固定格式将审阅开发人员的标记添加到提交中。这允许您过滤历史记录。如前所述，如果需要，可以使用源代码版本控制工具的预提交钩子来强制执行此操作。

然后，在没有同行评审的情况下不能提交代码的规则需要传达给所有开发人员。还显示了在提交之前检查代码的优点。最初的几个月，有人应检查提交的提交历史记录，而无需审阅者标记。如果他们找到了一些，请询问开发人员为什么要进行审核以及与谁进行审核。没有审查时，请提醒他们遵守规则。如果一些开发人员多次故意违反此规则，可能会产生影响，但同伴压力通常会阻止这种情况发生。

通常情况下，没有理由在此规则生效时不进行审核。特别是“但我必须快速解决这个问题以便为客户提供固定版本”不能成为借口，因为开发人员更有可能匆忙制造错误。

Answer 2

这个问题听起来像是像git或bzr这样的分布式VCS的广告：你需要开发人员能够经常提交更改，而不是自己的分支，然后在进入中央存储库之前对其进行审核。 / p>

Answer 3

就我个人而言，我每天经常承诺接近50次，所以我不喜欢它;）

我知道Atlassian的jira的greenhopper插件可以作为pre-committ钩子运行，以在提交中要求jira引用。如果您也使用greenhopper来规划开发任务，则可以强制所有提交都应该与jira问题相关联。

即使你没有使用greeenhopper，你也可以创建一个pre-committ钩子来强制执行包含一些问题跟踪引用号的提交注释。

这应该可以让你收集与jira问题相关的收集变更集，这对我来说听起来更好。

Answer 4

开发人员可以为每个更改（而不是每次提交）创建一个分支。他们可以在这个分支中承诺多次。但是，在将更改合并到主干之前，您可以强制执行同行评审。因此，您的主干只会包含经过同行评审的代码。

您可以通过权限执行此操作，因此只有选择人员可以提交到主干，并且他们可以在执行此操作之前检查代码是否正常。

我一直在使用版本控制，并认为在分支模型中工作（而不是在主干中工作）是好的。像git这样的DVCS系统更进了一步，似乎对很多人都有效。

Answer 5

您可以采用的一种方法是在团队中使用审核者提交规则。也就是说，不允许开发人员提交自己的代码，他们必须说服其他人代表他们提交代码。

之前我曾参与过这样的项目，而且效果相当好。缺点是使用Subversion，这意味着审阅者的名称，而不是开发人员的名称，显示在日志中。使用git，您可以保留开发人员的名称，并且审阅者添加一个Signed-off-by：行。