2010-04-13 19 views
1

我们致力于代码管理的git。我们正在努力寻找一个能帮助我们系统化代码评论的工具。我们正在考虑Gerrit和Code Collaborator,但会欢迎其他建议。我该如何协调代码审查工具和RCS(特别是git)

我们在回答这个问题时遇到了问题:“我们如何知道每一次提交都被审查过?” (或者“什么提交还没有被审查?”)

一个答案是提交每个提交或每个推动审查和追踪审查工具中的不完整的评论。我并不完全乐于依靠另一种工具 - 特别是如果它不是开源的 - 告诉我们这些。

似乎更好的答案是依靠git中的签名(例如,“签名:Chris Nelson”),并在审阅工具中使用钩子来签署代表审阅者的提交。这样做的好处是,如果我们对某些提交使用其他审核机制,则我们只有一个地方可以查找结果。与此相关的一个问题是,我们无法在推送前审核,因为审阅工具不太可能访问开发人员的私有存储库克隆以添加签名。

关于将代码审查与代码管理集成以实现易用性和未查看更改的高可见性的任何想法?

回答

0

我看到两种方法可以做到这一点,每一个都有自己的缺点:

1)建立一个代码合作者相变触发从一个“未被研究”分支自动合并涉及变更表中的“审查”分支时审查完成。这个问题的两个主要问题是:1)如果审核重新开放会怎么样? 2)合并必须能够自动工作。

2)通过编写一个脚本,向git提供您想要查看的主要开发分支中涉及的所有更改列表,然后向代码协作者询问已标记为已完成评价的所有更改列表的列表。从前者中减去后者,最终得到主开发分支中未被查看的变更列表。

声明:我聪明的熊软件工作,代码合作者

+0

谢谢,但我们尝试CC几个月,并搁置它。它真的不适合我们。 – 2011-11-04 18:54:12

0

的制造商把信息到提交的元数据将是最好的(GIT签收或其他但是你可以管理它)。告诉审查哪些提交比查看提交本身更好的方法?

其他有些东西我的团队已经在过去的尝试:

1)我们用拉力故事和拉力-TFS插件各关联承诺一个故事。我们将逐个故事地生成评论,并跟踪哪些故事已在Rally中进行了审核。

2)我们有一个自定义工具,它可以找到代码管理系统中两个检查点之间的所有提交,并且会检查自上一个检查点以来的所有更改。通过确保我们对每个检查点进行了审查,我们知道我们绝不会错过任何提交。检查点可以是每日,每周,基于里程碑......无论如何使审查大小可管理。

这两种方法都有缺陷,但是他们满足了我们100%确定所有提交都被审查过的需求。

+0

我认为答案在于Git笔记。我们可以将一些评论结果存储在笔记中,并查找没有笔记的任何提交。老版本的Git不会在没有工作的情况下推动笔记,但我们认为我们可以解决这个问题。 – 2011-11-04 18:55:35