我们理解，但我们只在GitLab EE中提供这个功能，因为我们认为通常锁定工作流对大型组织来说更有趣。
在一个小团队中，在某个工作流上达成一致要容易得多，因此拥有一个严格的工具就不那么重要了，而拥有一个灵活的工具就更有利了。
在您的团队中，您可以考虑使用“thumbsup”（通过书写：+1：）作为批准的计数器，并在您自己之间商定一个最小值。+1将在MR中求和。
©乔布·货车德沃特

更新2020年9月现在Core中有合并请求批准-Introduced in GitLab 13.2

但它们是可选的。您不能将其分配给某个用户。

据我所知，你不能从CE迁移到EE，因为CE是免费的，而EE不是。
但你能做的是：
1.使用 GitLab.com，在那里你可以免费获得所有的EE特性;

• 我以前从未尝试过CE，但您可能会在那里找到以下特性：
• 将用户添加到项目中并给予他们不同的访问级别。您可以定义哪些级别允许合并或不允许合并;
• 为特定用户分配合并请求，以便只允许受理人进行合并;
• 在添加与问题相关的MR之前打开该问题，以便人们可以在添加MR之前讨论问题的概要。当您向提交的邮件添加问题编号时，该问题将在合并时自动关闭。

我不知道这是不是你想要的答案，但我希望能有所帮助。

这是目前不可能的。我不知道任何插件来实现它。
你可以用“竖起大拇指”的React来投票（并订阅）已经存在的问题和关于该问题的讨论：
https://gitlab.com/gitlab-org/gitlab-ce/issues/42096

虽然合并请求审批不是免费GitLab层的一部分，但合并请求用户界面上仍然提供该功能，API中也提供数据，因此 * 作为一种解决方案 *，您可以创建一个GitLab CI作业，执行审批数量检查，如果数量不足则失败。
首先，确保在项目的合并请求设置中启用了Pipelines must succeed。
然后在.gitlab-ci.yml中创建一个新作业，该作业将在合并请求批准不足时失败：

code_approved:
  rules:
    - if: $CI_MERGE_REQUEST_ID
  script:
    - apt-get update
    - apt-get install -y jq curl
    - >
      curl --header "JOB-TOKEN: $CI_JOB_TOKEN"
      "$CI_API_V4_URL/projects/$CI_PROJECT_ID/merge_requests/$CI_MERGE_REQUEST_IID/approvals" 
      | jq -e '.approved_by[0]'

• apt-get ...：安装curl和jq二进制文件。
• curl -H "JOB-TOKEN: $CI_JOB_TOKEN"：验证呼叫。
• "$CI_API_V4_URL/projects/$CI_PROJECT_ID/merge_requests/$CI_MERGE_REQUEST_IID/approvals" GitLab API端点返回当前合并请求的批准数据。请注意，在GitLab Free上，此资源返回的许多数据丢失或具有误导性，但approved_by已正确填充。
• | jq -e '.approved_by[0]'通过管道将输出传输到jq，尝试从列表中提取第一个approved_by项。-e可确保在找不到该项时，命令将返回错误退出状态，这将导致CI作业失败，进而导致选项合并被阻止。如果需要两个审批，请使用jq筛选器'.approved_by[1]'。

演示：https://gitlab.com/blaisekal/mr-approvals/-/merge_requests
此解决方法的最大缺点是您需要运行作业来确定已批准状态，如果批准数发生变化，则必须手动重新运行作业，并且您团队中的恶意成员可能会在合并之前删除配置项作业。