合并请求、审核流程以及在 GitLab 中使用注释

自 2016 年以来，GitLab 已经取得了长足的发展，新的 13.1（2020 年 6 月）添加了一项与您的用例相关的功能：

\n
将任何设计线程标记为已解决
\n
当您收到大量有关设计的反馈时，评论引脚的数量会迅速增加！
\n随着讨论线程的增长，很难知道哪些讨论已经完成，哪些还需要工作。
\n
在 13.1 中，您\xe2\x80\x99 将能够将任何评论标记为“已解决”，以表示它现已完成。
\n
\n
更好的是\xe2\x80\x94，您解析的注释引脚将从设计中消失，这样您就可以专注于剩下的\xe2\x80\x99！
\n
当然，如果您需要重新访问某些内容，所有已解决的主题都将在侧边栏底部的已解决评论区域中提供。从那里，您可以再次找到它们并查看修订时应用了哪个修订。
\n
我们认为这将极大地改善您的工作流程，以便您可以专注于重要的事情。
\n

请参阅文档和问题

GitLab 13.5（2020 年 10 月）将在合并请求参与者（“受让人”）和审阅者之间添加明确的区别：

\n
为了弥补这些差距，GitLab 13.5 引入了合并请求“审阅者”，它可以轻松地允许作者请求审阅并查看审阅的状态。
\n只需从“审阅者”字段中选择一个或多个用户，指定的审阅者将收到有关审阅合并请求的请求的通知。
\n
这样可以轻松确定合并请求中涉及的用户的相关角色，以及正式请求同行进行审核。
\n

GitHub 已经可以请求拉取请求审核

使用GitLab 13.7（2020 年 12 月），您对审阅者有了更清晰的定义：

\n
合并请求的审阅者
\n
要求同事审查您的代码应该是贡献代码的常规部分，但它\xe2\x80\x99 往往不必要地复杂。
\n
像请求审查这样的简单任务可能会导致混乱。例如，你应该如何提问？一封电邮？评论？聊天消息？
\n
如果没有正式的流程，审核可能会不一致并且难以跟踪。以前，一个选项是为合并请求分配审阅者，但即使采用这种形式，作者和审阅者都出现在同一个受让人字段中，这使得其他团队成员很难知道谁在做什么。
\n
GitLab 13.7 引入了合并请求的审阅者，这允许作者请求某人进行审阅。
\n新的 \xe2\x80\x9cReviewers\xe2\x80\x9d 字段允许用户以与受托人类似的方式被指定为审阅者。审阅者会收到邀请他们审阅合并请求的通知。
\n
这提供了请求审核的正式流程，并澄清了合并请求中每个用户的角色。
\n
未来的迭代将包括显示与合并请求最相关的审阅者，以及将审阅者置于中心的简化合并请求批准流程。
\n您可以按照合并请求审阅者分配史诗了解更多详细信息。
\n
\n
请参阅文档和问题。
\n

另请参阅GitLab 14.6（2021 年 12 月）

\n
查看内联合并请求线程过时的更改
\n
在处理合并请求中的审阅反馈时，您经常会更改审阅者已评论的行。
\n在这些评论线程中，GitLab 表示做出了新的更改。
\n
然而，为了了解这些新的更改是否解决了反馈问题，审阅者必须脱离讨论的背景。
\n
现在，当查看与旧更改相关的线程时，您可以直接在线程中查看新更改。
\n这种改进的上下文可以帮助您更快、更准确地复习。
\n
\n
请参阅文档和问题。
\n

以及GitLab 15.3（2022 年 8 月）：

\n
提交合并请求审核以及摘要评论
\n
当您完成审查合并请求时，您可能会做一些常见的事情，例如为其他人总结您的审查或批准更改（如果您认为更改不错）。这些常见任务现在变得更快、更容易：当您提交评论时，您可以添加摘要评论以及任何快速操作，例如/approve。
\n
\n
请参阅文档和问题。
\n