我们有超过50个开发人员组成的大型团队。代码通过合并请求（MR）合并到主服务器，并且每个合并请求必须由任何其他队友进行审核和批准。问题是我有时会陷入MR / rebase竞赛。我尝试合并，失败了，其他人在我之前潜入了MR。所以我变基了。尝试合并，失败，别人在我面前悄悄溜走。所以我变基了。有时，我需要2-3个基础才能赢得比赛。
在GitLab中是否有一种方法可以“保留”合并的权利，从而确保您排在下一个？或至少说：“您无法合并，因为另一个用户保留了您要修改的文件”。我不得不浪费时间滚动骰子看我的代码是否合并，这似乎很愚蠢。
我们之前使用的VCS（ClearCase）具有这种确切的机制。您可以“保留”文件，以便仅允许您签入文件。其他任何人（除了管理员）都将被拒绝。
答案 0 :(得分：1)
GitLab EE允许file locking并在合并请求期间通知文件已锁定：
当用户不是文件锁定状态的作者时 接受合并请求，将显示一条错误消息，指出 文件已锁定。
合并请求也可以是prioritized using labels or issue deadlines。您可以检查this question about merge request priority和how GitLab community are organizing them