gitlab合并请求。谁是受让人?

有 documentation 为此。它指出:

此人拥有合并请求,但不负责审核。

此外,该文档还解释了一个示例 merge request workflow :

1. 您通常会创建MR 之前 正在处理您的功能分支。
2. 然后您可以使用 Assign to me 功能,表示您是当前正在实现MR功能的人。
3. 工作完成后,你可以 request a review 下列的 these guidelines .
4. 之后 finishing the review 你可以回到中的第8步 MR workflow .

被分配到合并请求的人是负责合并的人,而不是在审查的意义上。
通常是创建拉取请求的人对此负责,即当所有审核人员都满意并根据审核人员的意见批准或进行更改时,有责任进行合并。

然而,多个人可能会承担这一责任,因为这并不总是由一个人来承担(如果这个人去度假怎么办?)。 另一种情况是,如果多个开发人员一直在处理同一功能,因此对合并请求中的代码负有共同责任。

它实际上在中进行了描述 Gitlabs Documentation for Merge Request

TL;DR多人可以对合并请求负责。

我在实践中的经验,以及在阅读这个问题的其他答案时可以看到的是,虽然gitlab可能对如何使用这个领域有一个预定义的想法,但许多团队使用这个功能的方式不同。最好询问您的团队/公司如何使用此字段。

我在工作时看到的是以下工作流:

1. 创建MR后,将评审员分配为asignee
2. 现在他复习了,他指定你为助理
3. 然后你处理他的审查意见,然后再次将他指定为受让人,因为他现在应该最后查看MR,并可能批准它