在 GitLab 中合并请求、审查过程和使用评论 [英] Merge Request, Review process and using comments in GitLab

查看:220
本文介绍了在 GitLab 中合并请求、审查过程和使用评论的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我们目前正在评估我们项目中 GitLab 的使用情况,我们发现有一点不妥,那就是审查合并请求时的评论.

当在代码审查过程中输入一些评论并推送新的提交以解决这些评论时,问题就开始了.

对提交所做的评论和在更改"面板上所做的评论都显示在讨论"选项卡上,但没有迹象表明围绕同一行进行了一些更改.转到更改"面板并查看最新到基础的比较 - 我得到了我所期望的(到目前为止在分支上所做的一切),但是我们没有看到上面覆盖着评论旧的提交或旧的审查.

我有一半的预期是,在讨论面板中,我会在每条评论下获得另一个部分,显示最近代码中的更改.或者能够在查看最新版本时访问更改"面板中的所有评论,甚至是对旧版本的评论.

在 GitLab 审核流程和管理评论方面,我是否遗漏了什么?

解决方案

自 2016 年以来,GitLab 有了长足的发展,

更好的是 - 您已解决的评论引脚将从设计中消失,因此您可以专注于剩下的内容!

当然,如果您需要重新访问某些内容,所有已解决的话题都将在侧边栏底部的已解决评论区域中提供.从那里,您可以再次找到它们并查看在修订时应用了哪个修订.

我们认为这将大大改善您的工作流程,让您可以专注于重要的事情.

请参阅

<块引用>

为了弥补这些差距,GitLab 13.5 引入了合并请求审阅者".这让作者可以轻松地请求审阅以及查看审阅状态.
通过简单地从评论者"中选择一个或多个用户,就可以在字段,分配的审阅者将收到有关审阅合并请求的请求的通知.

这样可以轻松确定参与合并请求的用户的相关角色,以及正式请求同行评审.

请参阅

请参阅 文档问题.

We're currently evaluating the use of GitLab for our project and one thing we find slightly off is the comments when reviewing a merge request.

The problems starts when some comments were entered as part of the code review and a new commit was pushed to address these comments.

Both the comments made on the commits and those made on "Changes" panel are shown on the "Discussion" tab, but there's no indication that some changes around the same lines were made. Going to "Changes" panel and looking at the latest-to-base comparison - I get exactly what I'd expect (everything done on the branch thus far), but then we have no was to see that overlaid with comments made on the old commits or old review.

I was half-expecting that in the discussion panel I'd be getting another section under each comment showing what was changed in the code recently. That, or be able to access all the comments ever made in the "Changes" panel when looking at the latest, even comments made on older versions.

Is there something I'm missing here when it comes to GitLab review process and managing comments?

解决方案

GitLab has evolved considerably since 2016, and the new 13.1 (June 2020) adds a feature which is relevant for your use case:

Mark any Design thread as resolved

When you receive lots of feedback on a Design, the number of comment pins can build up quickly!
As your discussion thread grows, it gets hard to know which discussions are complete and which still need work.

With 13.1, you’ll have the ability to mark any comment as Resolved to signify that it is now complete.

Even better — your resolved comment pins will disappear from the Design so you can focus on what’s left!

And, of course, if you need to revisit something, all of your resolved threads will be available in the Resolved Comment area at the bottom of the sidebar. From there, you can find them again and see which revision applied at the point of revision.

We think this will greatly improve your workflow so you can focus on what is important.

See Documentation and Issue


GitLab 13.5 (Oct. 2020) will add a clear distinction between merge-request participants ("assignee") and reviewers:

To bridge these gaps, GitLab 13.5 introduces merge request "reviewers," which easily allows authors to request a review as well as see the status of the review.
By simply selecting one or more users from the "reviewers" field, the assigned reviewers will receive a notification of the request to review the merge request.

This makes it easy to determine the relevant roles for the users involved in the merge request, as well as formally requesting a review form a peer.

Requesting a pull request review is already available for GitHub


With GitLab 13.7 (December 2020), you have a clearer definition of reviewers:

Reviewers for Merge Requests

Asking a colleague to review your code should be a routine part of contributing code, but it’s often needlessly complex.

A simple task like asking for a review can lead to confusion. For example, how should you ask? An email? Comment? Chat message?

Without a formal process, reviews can be inconsistent and hard to keep track of. Previously, an option was to assign a reviewer to a merge request, but even with this formality, both the author and the reviewer appeared in the same assignee field, making it hard for other team members to know who was doing what.

GitLab 13.7 introduces reviewers for merge requests, which allows authors to request a review from someone.
The new "Reviewers" field allows users to be designated as reviewers in a similar way to assignees. The reviewers receive a notification inviting them to review the merge request.

This provides a formal process for requesting a review and clarifies the roles of each user in a merge request.

Future iterations will include showing the most relevant reviewers for a merge request as well as a streamlined merge request approval flow that puts reviewers at the center.
You can follow along in the merge request reviewer assignment epic for more details.

See Documentation and Issue.


See also GitLab 14.6 (December 2021)

View inline the change that outdated a merge request thread

When addressing review feedback in merge requests, you often change lines your reviewers have commented on.
In those comment threads, GitLab indicates that new changes were made.

However, to understand if those new changes address the feedback, reviewers would have to navigate away from the context of the discussion.

Now, when viewing threads related to old changes, you can view the new changes directly in the thread.
This improved context helps you review faster and more accurately.

See Documentation and Issue.

这篇关于在 GitLab 中合并请求、审查过程和使用评论的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆