我们目前正在为我们的项目评估 GitLab 的使用情况，我们发现有一点有点不对劲，那就是审查合并请求时的 cmets。
在代码审查过程中输入了一些 cmets 并推送了新的提交以解决这些 cmets 时，问题就开始了。
提交时所做的 cmets 和“更改”面板上所做的 cmets 都显示在“讨论”选项卡上，但没有迹象表明围绕同一行进行了一些更改。转到“更改”面板并查看最新到基础的比较 - 我得到了我所期望的（到目前为止，在分支上所做的一切），但是我们没有看到上面覆盖了 cmets旧的提交或旧的审查。
我有一半的预期是，在讨论面板中，我会在每条评论下获得另一个部分，显示最近代码中的更改。或者在查看最新版本时，甚至可以访问在“更改”面板中创建的所有 cmets，甚至是在旧版本上创建的 cmets。
在 GitLab 审核流程和管理 cmets 方面，我是否遗漏了什么？
【问题讨论】：
标签： gitlab
GitLab 自 2016 年以来发展迅速，new 13.1 (June 2020) 添加了一项与您的用例相关的功能：
将任何设计线程标记为已解决
当您收到大量有关设计的反馈时，评论针的数量会迅速增加！
随着讨论线程的增长，很难知道哪些讨论已经完成，哪些还需要工作。在 13.1 中，您可以将任何评论标记为已解决，以表示它现在已完成。
更好的是——您已解决的评论图钉将从设计中消失，因此您可以专注于剩下的内容！
当然，如果您需要重新访问某些内容，所有已解决的主题都将在侧边栏底部的已解决评论区域中提供。从那里，您可以再次找到它们并查看在修订时应用了哪个修订。
我们认为这将大大改善您的工作流程，让您可以专注于重要的事情。
GitLab 13.5 (Oct. 2020) 将明确区分合并请求参与者（“受让人”）和审阅者：
为了弥合这些差距，GitLab 13.5 引入了合并请求“审阅者”，作者可以轻松地请求审阅以及查看审阅状态。
只需从“审阅者”字段中选择一个或多个用户，分配的审阅者就会收到有关审查合并请求的请求的通知。这样可以轻松确定参与合并请求的用户的相关角色，以及正式请求同行评审。
Requesting a pull request review 已经可用于 GitHub
使用GitLab 13.7（2020 年 12 月），您对审阅者的定义更加清晰：
合并请求的审阅者
请同事审查您的代码应该是贡献代码的常规部分，但它通常是不必要的复杂。
请求评论之类的简单任务可能会导致混乱。例如，你应该怎么问？一封电邮？评论？聊天消息？
如果没有正式的流程，评论可能会前后不一致且难以跟踪。以前，一个选项是为合并请求分配审阅者，但即使采用这种形式，作者和审阅者也会出现在同一个受理人字段中，这使得其他团队成员很难知道谁在做什么。
GitLab 13.7 引入了合并请求的审阅者，允许作者向某人请求审阅。
新的“审阅者”字段允许以与受让人类似的方式将用户指定为审阅者。审阅者会收到邀请他们审阅合并请求的通知。这为请求审查提供了一个正式的流程，并阐明了每个用户在合并请求中的角色。
未来的迭代将包括显示与合并请求最相关的审阅者，以及以审阅者为中心的简化合并请求审批流程。
您可以关注merge request reviewer assignment epic了解更多详情。请参阅 Documentation 和 Issue。
另见GitLab 14.6（2021 年 12 月）
内联查看使合并请求线程过时的更改
在处理合并请求中的审阅反馈时，您通常会更改审阅者评论过的行。
在这些评论线程中，GitLab 表示进行了新的更改。但是，要了解这些新更改是否解决了反馈问题，审阅者必须远离讨论的背景。
现在，在查看与旧更改相关的线程时，您可以直接在线程中查看新更改。
这种改进的上下文可帮助您更快、更准确地进行审核。参见Documentation 和Issue。
【讨论】：