修复GitLab错误:"您无权将代码推送到此项目的受保护分支"。
问题:当在GitLab上尝试推送代码到受保护的分支时,会出现错误提示:"you are not allowed to push code to protected branches on this project"。
出现原因:默认情况下,GitLab Enterprise Edition 9.3.0的主分支(master)是受保护的,不允许直接向其推送代码。
解决方法:取消分支的保护状态,允许推送代码。
1. 选择项目。
2. 选择“仓库”。
3. 选择“分支”。
4. 选择“项目设置”。
5. 在“受保护的分支”下点击“展开”。
6. 点击“取消保护”按钮。
如果在该仓库中尚未创建任何文件,则可能没有“分支”选项。请先创建一个Readme.md文件,然后分支选项将出现。
请注意,即使在小组织或公司中工作,也不要这样做,因为这会带来严重的安全问题。
在GitLab 13.11 (2021年4月)中,解决了一个常见问题:"you are not allowed to push code to protected branches on this project"。通常情况下,为了保护Git仓库的安全,不允许进行强制推送(force push),但在某些特殊情况下可能需要进行强制推送。
然而,在之前的版本中,为了进行强制推送,只能通过临时移除分支保护的方式来实现,但这样做需要具备项目维护权限,并且会导致分支保护的设置丢失,不太理想。
为了解决这个问题,GitLab 13.11 引入了一个新的设置选项:允许对受保护的分支进行强制推送(Allow force push)。只有在“Allowed to push”列表中的用户才能进行强制推送。具体设置如下图所示:
![Force push option for protected branches](https://i.stack.imgur.com/h0CM0.png)
此外,GitLab 16.2 (2023年7月)中还添加了一个新功能:"Allow initial push to protected branches"。在之前的版本中,当默认分支被完全保护时,只有项目维护者和拥有者才能向默认分支推送初始提交。这对于创建新项目的开发人员来说可能会造成问题,因为他们无法向默认分支推送初始提交。
为了解决这个问题,引入了一个新的设置选项:"Fully protected after initial push"。开发人员可以向仓库的默认分支推送初始提交,但之后不能再向默认分支推送任何提交。与完全保护的分支类似,项目维护者始终可以向默认分支推送,但没有人可以进行强制推送。具体设置如下图所示:
![Allow initial push to protected branches](https://i.stack.imgur.com/mgI9a.png)
通过以上的解决方案,可以在GitLab中解决"you are not allowed to push code to protected branches on this project"的错误。具体的设置方法和更多信息可以参考GitLab的官方文档和相关问题链接。
在GitLab中,一些分支可以被保护。默认情况下,只有Maintainer/Owner用户可以向受保护的分支提交代码(请参阅权限文档)。默认情况下,master
分支是受保护的,这样开发人员在将其集成到主要代码之前必须发出合并请求并由项目维护人员验证。
您可以在项目设置中打开和关闭对选定分支的保护(具体位置取决于GitLab版本-请参阅以下说明)。在同一设置页面上,您还可以允许开发人员向受保护的分支推送代码。打开此设置后,保护将限于拒绝需要git push --force
(如rebase等)的操作。
自GitLab 9.3版本以来:
转到项目:"设置"→"存储库"→"展开"在"受保护的分支"上
现在您可以选择谁被允许合并或推送到选定的分支(例如:您可以完全禁止对master
的推送,强制所有更改通过合并请求进行)。或者您可以点击"取消保护"完全移除分支的保护。
自GitLab 9.0版本以来:
与GitLab 9.3类似,但不需要点击"展开" - 一切已经展开:
转到项目:"设置"→"存储库"→向下滚动到"受保护的分支"。
GitLab 9.0之前:
项目:"设置"→"受保护的分支"(如果您至少是给定项目的"Master")。
然后点击"取消保护"或"开发人员可以推送"。
不要忘记可能需要一些权限。如docs.gitlab.com/ee/user/project/protected_branches.html所述,至少需要"Master权限级别"。在我的情况下,按下设置按钮只显示"离开项目"选项。
因为某种原因,我突然不得不将自己添加为我的项目的主用户。
我遇到这个问题是因为我没有成为我自己项目的成员,而我已经向该项目推送了代码...要更改它,在您的项目中,点击设置按钮,成员,搜索您的用户,给它一个角色,然后点击"添加用户到项目"。
奇怪,我也是,不得不在gitlab.com上的个人项目中包含自己。
疯了,如何将自己更改为所有者,列表中没有所有者选项。
在GitLab 9.0中,受保护的分支设置现在已经移至项目设置=>存储库=>受保护的分支,谢谢评论-回答已更新。
谢谢解决方案!你知道如何默认设置"取消保护"分支吗?
除了master
之外的所有分支默认情况下都不受保护(必须在创建时指定"通配符保护"来保护某些新分支)。master
的保护是默认的,无法更改(据我所知)。
非常感谢,这帮助了我从存储库中删除大文件/机密文件。最新位置由's answer详细说明。
如果您是唯一的维护者或开发者,那么您可以更改设置并进行调整。但是,如果有一个团队在仓库上工作,那么更改仓库的保护不是一个好习惯。
我的问题是,我想要一个受保护的通配符分支,但是我将推送访问权限设置为"无人",这意味着没有人可以推送新的分支。所以通配符分支+无推送访问权限永远不会有意义。
有没有办法确保用户可以推送代码,即使主分支受保护?我有几个项目是通过推送进行镜像的,两个项目的主分支受到保护,没有问题。最近我尝试使用相同的配置创建另一个项目,但现在突然无法推送到新项目,因为分支受到保护,但对于其他两个仓库来说这仍然不是一个问题。唯一的区别是其他两个仓库属于不同的用户,而第三个仓库属于与源仓库相同的gitlab组。对此有什么见解吗?
保护有两个独立的类别"允许合并"和"允许推送"。因此,选择的用户和/或组可以被允许推送到受保护的分支。我认为"免费"和"企业"版的GitLab之间可能存在差异-在免费版中只能选择组,对于单个用户我不确定。
我明白你的意思。我有一个仓库1,其中主分支受保护,除了维护者用户外,镜像工作正常,然而,我有一个第二个仓库,根据相同的设置,镜像失败。
在将现有代码库迁移到gitlab时,不得不禁用此功能以强制推送到主分支,然后再启用。
没有问题-一切正常。这是一个可怕的评论。问题在于首先出现的错误消息,导致人们在这里而不是直接找到解决方案!