Merge Request dependencies

Merge Request dependencies

版本历史

合并请求相关性允许表达合并请求之间的合并所需顺序. 如果合并请求”依赖”另一个请求，则在合并其依赖项之前，不能将其合并.

注意：合并请求依赖项是PREMIUM功能，但是此限制仅对依赖合并请求强制执行. CORE或STARTER项目中的合并请求可以是PREMIUM合并请求的依赖项，反之亦然.

  • 在更改导入库的项目之前，请确保对库的更改已合并.
  • 在实现要记录功能的合并请求之前，防止仅文档合并请求被合并.
  • 在合并来自尚未被授予权限的人的合并请求之前，要求合并请求更新要合并的权限矩阵.

单个逻辑更改通常会跨越多个合并请求，并分散到多个项目中，并且合并的顺序可能很重要.

例如，给定项目在myfriend/awesome-lib处导入了库，在awesome-project添加功能可能还需要更改awesome-lib ，因此需要两个合并请求. 在awesome-lib之前合并awesome-project合并请求会破坏分支.

awesome-project合并请求可以标记为Draft ，注释中包含所述草案的原因. 但是，这要求手动跟踪awesome-lib合并请求的状态，并且如果awesome-project合并请求依赖于对其他几个项目的更改，则伸缩性不好.

通过使awesome-project合并请求依赖于awesome-lib合并请求，此关系将由 GitLab 自动跟踪，草稿状态可用于在每个单独的合并请求中传达代码的就绪状态.

要继续上面的示例，您可以在创建新的合并请求时配置依赖项（或通过编辑（如果已经存在））. 需要在依赖合并请求上配置依赖 . 表单中有一个” 合并请求依赖项”部分：

任何可以编辑合并请求的人都可以更改依赖关系列表.

可以通过引用或 URL 添加新的依赖项. 要删除依赖项，请按其引用旁边的X.

由于可以在项目之间指定依赖关系，因此其他人可能为您无权访问的项目中的合并请求添加了依赖关系. 这些显示为简单计数：

如有必要，您可以按X来删除所有类似的依赖项，就像对单个可见的依赖项一样.

完成后，请按” 保存更改”按钮以提交请求，或按” 取消”以不做任何更改地返回.

合并请求窗口小部件中显示了已配置依赖项的列表以及每个依赖项的状态：

Dependencies in merge request widget

如果已关闭合并请求，并且依赖项不再相关，则必须在合并之前按照上述说明将其作为依赖项除去.

  • API 支持：
  • 不支持复杂的合并顺序相关性： 问题＃11393

最后一项值得更多解释. 合并请求之间的依赖关系可以描述为关系图. 最简单的图可能有一个合并请求，该合并请求取决于另一个：

图 LR; myfriend / awesome-lib！10-> mycorp / awesome-project！100;

更为复杂（且仍受支持）的图可能具有一个合并请求，该合并请求直接取决于其他几个：

图 LR; myfriend / awesome-lib！10-> mycorp / awesome-project！100; herfriend / another-lib！1-> mycorp / awesome-project！100;

几个不同的合并请求也可以直接依赖于同一合并请求：

图 LR; herfriend / another-lib！1-> myfriend / awesome-lib！10; herfriend / another-lib！1-> mycorp / awesome-project！100;

不支持的是依赖项的”深度”或”嵌套”图. 例如：

在此示例中， myfriend/awesome-lib!10取决于herfriend/another-lib!1 ，它本身是mycorp/awesome-project!100的依赖项. 这意味着myfriend/awesome-lib!10成为mycorp/awesome-project!100的间接依赖项，尚不受支持.