如何在Gitlab中更改合并的默认目标分支

我们将Gitlab 8.10.1用于许多组和项目。许多项目恰好是其他项目的分支。 我们的问题是，每当有人打开项目的合并请求时，默认的目标分支不是项目的默认分支，而是来自一个非常特定的其他项目。有没有办法以某种方式覆盖此设置？ 我只想说清楚，我知道如何设置项目的默认分支，这些设置看起来是正确的，但是gitlab在创建合并请求时似乎没有使用它们。

---

这个问题非常烦人，导致了一些奇怪的情况，人们没有注意到，并以一个完全不同的“master”作为目标发出合并请求。

我们找到了这种行为的根源，这是由于项目之间的关系，因为一个项目在gitlab中从另一个项目分支出来。删除源和分支之间的关系时，合并的默认分支是项目本身的默认分支。

---

现在这是我们针对这种情况的解决方案，因为我们可以接受删除sourcefork关系的影响。

您需要掌握。然后是项目设置---默认分支---保存更改

---

享受吧！

默认的MR目标取决于存储库是否是一个存储库

叉子 如果存储库是，那么默认的MR目标将是上游存储库的默认分支。可以通过“项目设置”页面上的“删除fork关系”选项删除此关系，然后将非fork存储库的默认MR目标确定为正常（如下所述）

在撰写本文时，如果不删除fork关系，就不可能覆盖默认的MR目标，但该功能已在gitlab问题中被请求

非叉子 如果存储库没有fork关系，则“项目设置”页面上的默认分支设置将同时设置（1）默认MR目标和（2）GitLab服务器上repo的头引用（这将确定克隆repo时签出的分支）。注意，由于一个错误，如果一个曾经是默认分支的分支后来从GitLab中删除

---

在撰写本文时，无法独立于默认分支更改默认MR目标，但此功能已在gitlab问题中提出请求。

从11.5.3版开始，设置略有更改。发件人：

创建新项目时，GitLab将master设置为项目的默认分支。您可以在项目的“设置”>“存储库”下选择另一个分支作为项目的默认分支

---

关于叉子，有一个有趣的特性（2021年4月）

为forks中的合并请求设置默认目标项目 在分叉一个项目之后，使用合并请求为上游项目做出贡献是有益的

以前，GitLab假设来自fork项目的合并请求总是以上游项目为目标。
这可能会造成错误，代码不应合并到上游，或者用户需要在打开合并请求之前进行更改

GitLab现在支持为在fork项目中创建的合并请求设置默认目标项目。
这简化了贡献，并有助于避免用户和团队的错误，这些用户和团队通常为他们的fork项目而不是上游项目做出贡献

见和

---

如果你能列出做这件事的步骤，那就更有用了。以防万一，有人需要它。支持编辑合并请求链接的目标分支：但请注意，这将更改克隆时使用的默认分支