88

如何使用 Gitlab 设置代码审查?我看到它在 Gitlab 网站上列为一项功能,但我似乎找不到有关如何设置的说明(就此而言,任何指向 Gitlab 用户手册的链接将不胜感激)。

我的一些搜索表明“合并请求”是要走的路……但我发现它们有限制。发出的合并请求会显示一个分支与另一个分支之间的所有提交。我似乎只能查看为每个单独的提交生成的差异。例如,假设我有一个要查看的文件。这是一个新文件,但我已经在 dev 分支上提交了 10 次以上的更改。如果我从集成中为该开发分支发出合并请求,我会看到 10 个提交,每个提交都显示对文件所做的增量更改......我想查看整个事情。它是新的!

我在这里吠错树了吗?是否有我可以在 GitLab 中使用的实际代码审查工具,或者合并请求是可行的方法,如果它们是我错误地使用它们?在这里设置适当的代码审查的最佳方法是什么?

4

5 回答 5

25

注意:从 GitLab 6.4 开始,可以使用并排差异视图:请参阅“拉取请求 5308 ”。

(2013 年 7 月)不过,目前还不可能对每一行进行评论,只能在文件级别。
Daniel Sokolowski在评论中提到现在支持每行评论(09/2014):

您的团队成员可以对合并请求进行一般评论,也可以使用行评论对特定行发表评论。

这仍然有助于代码审查活动。

https://f.cloud.github.com/assets/4224518/1558702/e0fe633a-4fa3-11e3-9388-3f3e445cb6d4.png


6 年后,对于GitLab 13.1(2020 年 6 月)

合并请求评论移至核心

最初在 GitLab 11.4 中作为 GitLab 高级功能引入,合并请求审查允许合并请求审查者:

  • 一次提交多条评论,
  • 减少合并请求作者的通知噪音,以及
  • 允许更有凝聚力和简化的审查过程。

https://about.gitlab.com/images/13_1/batch_comments.png

自推出以来,我们重新评估了它在基于买方的定价模型中的位置,作为 13.1 的一部分,我们很高兴地宣布此功能现已移至 GitLab 核心。

请参阅文档问题


使用GitLab 13.9(2021 年 2 月),您还拥有:

请求审阅者进行后续审阅

合并请求作者收到审阅者的反馈。通常,需要重新审查这些反馈,以确保所有问题都得到适当解决。作为投稿的作者,您需要向审阅者传达后续跟进的需求。

对于已经审阅过合并请求的审阅者,您现在可以请求重新审阅。此请求会触发待办事项和电子邮件通知,以提醒用户您需要对您的贡献进行后续审查。

https://about.gitlab.com/images/13_9/create_code_review-request-re-review.png -- 向审稿人请求后续审稿

请参阅文档问题


使用GitLab 13.11(2021 年 4 月)

添加独立评论以合并请求评论

在查看更改时,您可能想要总结您的反馈,或评论与特定更改无关的内容。GitLab 中的评论只允许评论更改或回复现有评论,这意味着必须在提交评论后进行其他类型的评论。

作为审核过程的一部分,您现在可以提交一般性评论以及您的回复或特定于更改的评论。一般评论使向作者提供反馈和使用快速操作来更新合并请求中的项目变得简单。

感谢Lee Tickett的贡献!

https://about.gitlab.com/images/13_11/code-review-add-comment-mr-review.png -- 添加独立评论以合并请求评论

请参阅文档问题

于 2014-01-23T12:58:49.517 回答
9

我在 Gitlab 中进行代码审查已经两个多月了,几乎没有摩擦。我已经设置rss2email以在开发人员每次推送新提交时发送电子邮件通知。然后我使用 Gitlab 的评论功能进行提交,对推送的代码进行一些评论。

不幸的是,Gitlab 不允许对文件本身进行评论,只能在提交中进行评论(就像 Github,我猜)。每当我发现自己需要对之前提交中遗漏的内容进行评论时,我都会使用责备工具来查找引入/更改了要评论的代码部分的提交。

它远非完美,但到目前为止它运行良好。

于 2013-12-26T12:32:01.240 回答
2

您可以在其他存储库或当前存储库的合并请求中查看提交的代码。
示例http://demo.gitlab.com/diaspora/diaspora/commits/master

然后您可以将注释添加到提交的文件更改(按钮Reply)或整个提交

示例http://demo.gitlab.com/diaspora/diaspora/commit/42f47626890218a180870bc3f44ec57625b0779c

由此产生的沟通是代码审查。但是,我个人建议尽可能在一台 PC 上进行代码审查,并进行面对面的交流,并使用工具来记录结果或在需要更多形式时使用。

对于有很多提交的文件评论,例如http://demo.gitlab.com/diaspora/diaspora/blame/master/README.md 查看它blame以了解谁做了什么。但是,在此视图中,无法进行交流和添加评论。在这种情况下,我建议只添加更改作为注释。

于 2013-07-17T08:08:45.507 回答
1

是的。合并请求是完成同行评审的方式。

应该有一个“差异”选项卡,它将显示所有提交的更改(此处提到:http: //youtu.be/DyAX8ws5OIc?t= 3m2s)。

该视频还很好地解释了它如何用于同行评审。

于 2013-07-17T08:11:21.730 回答
0

代码审查的正常用例是在合并到 master 或类似分支之前审查分支上的代码。我有一种情况,我开发了一个项目,并希望团队中的每个人都审查所有代码。

我所做的是:

签出第一个提交,对其进行更改,提交并推送

git co -b FIRST_COMMIT eb67f06c2b3222c0219214b176c41922bc454881
vi README.md
git add README.md
git ci -m "First commit modified so can get full diff against it"
git push --set-upstream origin FIRST-COMMIT

签出最后一次提交,对其进行更改,提交并推送

git co -b master
vi README.md
git add README.md
git ci -m "Last commit modified so can get full diff against it"
git push --set-upstream origin LAST-COMMIT

在 GitLab / GitHub 上,创建一个拉取请求

  • 它是从 LAST_COMMIT 合并到 FIRST_COMMIT

为我工作!

于 2018-10-18T03:13:27.070 回答