我的存储库也遇到了同样的问题。我是仓库的主人，但我犯了这样一个错误。

我已经保护了我的项目，然后再次重新保护，错误就消失了。

在我之前的推送和有问题的推送之间，我们升级了gitlab版本。我想是这次升级造成了这个bug。

没有问题，一切都按预期进行。

在GitLab中，可以保护一些分支。默认情况下，只有维护者/所有者用户可以提交到受保护的分支(参见权限文档)。默认情况下主分支是受保护的——它迫使开发人员在将合并请求集成到主代码之前发出合并请求，并由项目维护者进行验证。

你可以在项目设置中打开和关闭选定分支的保护(具体取决于GitLab版本-见下面的说明)。

在相同的设置页面上，您还可以允许开发人员推送到受保护的分支。在此设置下，保护将仅限于拒绝需要git push -force的操作(rebase等)。

自从GitLab 9.3

转到项目:“设置”→“存储库”→“扩展”在“受保护的分支”

我不太确定这个变化是什么时候引入的，截图来自10.3版本。

现在你可以选择谁被允许合并或推送到选定的分支中(例如:你可以完全关闭推送，强制所有对分支的更改通过合并请求进行)。或者你可以点击“取消保护”来完全从分支中移除保护。

自从GitLab 9.0

类似于GitLab 9.3，但不需要点击“展开”-所有东西都已经展开了:

进入项目:“设置”→“存储库”→向下滚动到“受保护的分支”。

终极吉他9.0

项目:“设置”→“受保护的分支”(如果你至少是给定项目的“Master”)。

然后点击“取消保护”或“开发者可以推送”:

替代解决方案，使用GitLab 13.11(2021年4月)

Force push option for protected branches It’s best practice to prevent force push on Git repos, but exceptional cases may occasionally require it. Temporarily removing branch protections in order to conduct a force push may not always be ideal as it requires maintainer access, and causes the settings for branch protection to be lost. GitLab 13.11 introduces a new Allow force push setting for protected branches, which enables users in the Allowed to push list to force push. See Documentation and Issue.

这个问题的简单解决方案是与在gitlab中拥有所有者角色的人进行快速聊天。他可以将一个文件推为READ。Md或者类似的开头。之后，一切都将像之前一样工作。

我也遇到过类似的问题。然而，问题是存储库被意外归档了!您可以通过转到存储库(至少在Gitlab中)进行检查，它显示了以下消息“已存档的项目!”存储库和其他项目资源是只读的。”为了向它推送，我们必须解压缩它。

对我来说，在创建个人访问令牌时，选择开发人员而不是维护人员的位置是一个问题。

选择维护者解决了这个问题。