576

I have a problem when I push my code to git while I have developer access in my project, but everything is okay when I have master access. Where is the problem come from? And how to fix it?

Error message:

error: You are not allowed to push code to protected branches on this project.
...
error: failed to push some refs to ...

starball
  • 20,030
  • 7
  • 43
  • 238
Fachrein Rachim Muhamad
  • 5,797
  • 2
  • 12
  • 8
  • Hcorg's answer is a good solution. There is another problem with it. If the project has just create and it has no branch yet. If click the "Protected branches", it will redirect to the project home page. Create a branch will work. – pdwjun Mar 20 '17 at 09:37
  • See also https://stackoverflow.com/a/61964599/6309, with GitLab 13.0 (May 2020), where you can enable group-level default branch protection. – VonC May 22 '20 at 22:08

16 Answers16

887

there's no problem - everything works as expected.

In GitLab some branches can be protected. By default only Maintainer/Owner users can commit to protected branches (see permissions docs). master branch is protected by default - it forces developers to issue merge requests to be validated by project maintainers before integrating them into main code.

You can turn on and off protection on selected branches in Project Settings (where exactly depends on GitLab version - see instructions below).

On the same settings page you can also allow developers to push into the protected branches. With this setting on, protection will be limited to rejecting operations requiring git push --force (rebase etc.)

Since GitLab 9.3

Go to project: "Settings" → "Repository" → "Expand" on "Protected branches"

enter image description here

I'm not really sure when this change was introduced, screenshots are from 10.3 version.

Now you can select who is allowed to merge or push into selected branches (for example: you can turn off pushes to master at all, forcing all changes to branch to be made via Merge Requests). Or you can click "Unprotect" to completely remove protection from branch.

Since GitLab 9.0

Similarly to GitLab 9.3, but no need to click "Expand" - everything is already expanded:

Go to project: "Settings" → "Repository" → scroll down to "Protected branches".

enter image description here

Pre GitLab 9.0

Project: "Settings" → "Protected branches" (if you are at least 'Master' of given project).

Settings → Protected branches

Then click on "Unprotect" or "Developers can push":

enter image description here

Uwe Keim
  • 39,551
  • 56
  • 175
  • 291
Hcorg
  • 11,598
  • 3
  • 31
  • 36
  • Don't forget that there may be required some permissions. As stated in http://docs.gitlab.com/ee/user/project/protected_branches.html, at least 'Master permission level'. In my case pressing on a settings wheel shows only 'Leave Project` option. – CoolMind Aug 28 '16 at 20:13
  • 2
    For some reason I suddenly had to add myself as a master user for my own project. – jgillich Sep 17 '16 at 01:28
  • 5
    I got this problem because I was NOT a member of my OWN project and i already pushed on this project... To change it, in tour project, click the gear, Members, search your user, give it a role and click "Add users to project". – Loenix Sep 19 '16 at 15:18
  • Strange, me too, had to include myself on a personnal project on gitlab.com – Thomas Decaux Jan 06 '17 at 15:28
  • crazy, how to change my self to owner, no owner option on list – Donny Gunawan Jan 06 '17 at 15:47
  • In GitLab 9.0, protected branches settings have now moved to Project settings => Repository => Protected Branches – Bancarel Valentin Apr 05 '17 at 14:03
  • @BancarelValentin thanks for comment - answer updated :) – Hcorg Apr 05 '17 at 21:25
  • Thanks for solution! Do you know how set "unprotected" branches by Default? – Adobe May 16 '17 at 04:13
  • @Adobe all branches except for `master` are not protected by default (one has to specify "wildcard protection" to make some new branches protected on creation). `master`'s protection is by default and that can't be changed (AFAIK). – Hcorg May 16 '17 at 10:08
  • Thanks so much this helped me [remove large/secret files](https://docs.gitlab.com/ce/user/project/repository/reducing_the_repo_size_using_git.html) from the repository. Latest location is in detailed by @krekto's answer. – jchook Feb 27 '18 at 02:11
  • 1
    It is good if you are the only maintainer or developer, so you can change the setting and play around with it. But if there is a team working on the repo, then it is not a good practice of changing the protection of the repo. – Mnemo May 31 '19 at 02:55
  • My problem was I wanted to have a protected wildcard branch but I had push access set to "no one" which - surprise - allows no one to push a new branch. So wildcard branches + no push access shouldn't ever make sense – boy May 23 '21 at 17:59
  • Is there any way to ensure a user can push even though the master is protected? I have a couple of projects which are mirrored with push and the master branch is protected on two of them with no problem. I tried recently making another one with the same configuration and now suddenly I can not push to the new one because the branch is protected, yet for the other two repositories that is still not an issue. The only difference being that the other 2 repositories are from different users while the third one is under the same gitlab group with the source repository. Any insight on this? – Iustinian Olaru Jul 08 '21 at 13:56
  • @IustinianOlaru protection has two separate categories "allowed to merge" and "allowed to push". So selected users and/or groups can be allowed to push to protected branches. I think there might be a difference between "free" and "enterprise" GitLab - in free only groups can be selected, I'm not sure about single users. – Hcorg Jul 08 '21 at 20:49
  • @Hcorg I see what you mean. I have a repository 1 which has the master branch protected except for maintainer users and to that repository mirroring works fine, however I have a second repository to which mirroring fails under the same settings. – Iustinian Olaru Jul 12 '21 at 09:16
  • Had to disable this to force push to master when migrating an existing code base into gitlab. Then enable it again afterwards. – James McCorrie Nov 05 '21 at 11:49
  • there's no problem - everything works as expected That is a horrible comment. The problem is the error message in the first place that leads people here instead of directly to the solution! – Wolfgang Fahl Apr 13 '23 at 12:37
57

for the GitLab Enterprise Edition 9.3.0

By default, master branch is protected so unprotect :)

1-Select you "project"

2-Select "Repository"

3-Select "branches"

4-Select "Project Settings"

5-In "Protected Branches" click to "expand"

6-and after click in "unprotect" button

krekto
  • 1,403
  • 14
  • 18
  • I didn't have "branches" because I didn't create any file on this repository yet. I've created Readme.md and branches appeared. – Ikrom Aug 16 '18 at 10:08
  • 1
    For the passersby... please don't do this. Even if you work in a small org/company it opens up serious security issues – djthoms Jan 24 '22 at 17:30
19

Alternative solution, with GitLab 13.11 (April 2021)

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.

https://about.gitlab.com/images/13_11/code_owners_approval_new_protected_branch_v13_10.png -- Force push option for protected branches

See Documentation and Issue.

Also, GitLab 16.2 (July 2023) adds:

Allow initial push to protected branches

In previous versions of GitLab, when a default branch was fully protected, only project maintainers and owners could push an initial commit to a default branch.

This caused problems for developers who created a new project, but couldn’t push an initial commit to it because only the default branch existed.

With the Fully protected after initial push setting, developers can push the initial commit to the default branch of a repository, but cannot push any commits to the default branch afterward. Similar to when a branch is fully protected, project maintainers can always push to the default branch but no one can force push.

https://about.gitlab.com/images/16_2/govern-initial-push-protected-branch.png -- Allow initial push to protected branches

See Documentation and Issue.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
7

To the settings after opening the branch in git. Then allow force push.

Allow to force push option

Suraj Rao
  • 29,388
  • 11
  • 94
  • 103
Mizanur Rahman
  • 97
  • 1
  • 4
5

When you have error message remote: You are not allowed to push code to this project. and The requested URL returned error: 403

Try setting the git user,

To prompt username before pushing the Code, use

$ git config --local credential.helper ""

After entering Username and Password and successful login

$ git push
ravthiru
  • 8,878
  • 2
  • 43
  • 52
4

I was on Windows when this problem appeared.

The error is strange because it happens before I could enter my username and my password. What if there was a cache or something like this? I dig it online and found this answer on gitlab's support forum:

I open "Control Panel => User Accounts => Manage your credentials => Windows Credentials" I found two for https://@github.com and one was the wrong user. I deleted it and on the next "git push" I was reprompted and provided the correct credentials and it worked! Some other notes - this could have happened with any git remote.

In the Windows Credentials, I found two GitLab entries for an old account. I remove both and now it works!

The panel:

enter image description here

aloisdg
  • 22,270
  • 6
  • 85
  • 105
3

This is considered as features in Gitlab.

Maintainer / Owner access is never able to force push again for default & protected branch, as stated in this docs enter image description here

mochadwi
  • 1,190
  • 9
  • 32
  • 87
  • 1
    Actually this isn't unfortunate at all. It's definitely a good thing. It's an extra layer of protection. – Chiramisu Jun 03 '20 at 20:22
2

I have encountered this error on "an empty branch" on my local gitlab server. Some people mentioned that "you can not push for the first time on an empty branch". I tried to create a simple README file on the gitlab via my browser. Then everything fixed amazingly and the problem sorted out!! I mention that I was the master and the branch was not protected.

Vahid F
  • 377
  • 1
  • 7
  • 21
  • 1
    This is odd for me and I consider this issue as a gitlab bug. It's unacceptable for me to have no permission to push into an empty repo. I hope git guys have an answer for it. – Vahid F Jun 30 '18 at 05:40
2

Try making changes as per link

https://docs.gitlab.com/ee/user/project/protected_branches.html

make the project unprotected for maintainer or developer for you to commit

Barath Ravichander
  • 159
  • 1
  • 8
2

For me, it was an issue of choosing Developer rather than Maintainer position while creating a personal access token.

Choosing Maintainer solved the situation.

Curious Watcher
  • 580
  • 6
  • 12
1

I experienced the same problem on my repository. I'm the master of the repository, but I had such an error.

I've unprotected my project and then re-protected again, and the error is gone.

We had upgraded the gitlab version between my previous push and the problematic one. I suppose that this upgrade has created the bug.

Stephen Ostermiller
  • 23,933
  • 14
  • 88
  • 109
jean pierre huart
  • 370
  • 1
  • 12
1

Simple solution for this problem to have quick chat with person who has owner role in gitlab. He can push one file READ.md or similar to just start with. Later, everything will be working as earlier.

kris
  • 979
  • 11
  • 15
  • If possible, try to get the owner role in repository. Once you have owner role, you can commit directly to master. It's annoying but preventive hook not to create unwanted new projects.There is no hack around until owner of repo push the first file or you have owner role. Hope this helps. – kris Sep 13 '19 at 21:36
0

I encountered a similar issue. However, the problem was that the repository was accidentally archived! You can check by going to the repository (in Gitlab at least) and it showed the following message "Archived project! Repository and other project resources are read-only." In order to push to it, we had to unarchive it.

Chris
  • 131
  • 4
0

For me the problem was the user trying to push simply was not invited to the project. I had to go to Project Information > Members and invite the member as a developer so they had access to push.

lucky.expert
  • 743
  • 1
  • 15
  • 24
0

This works for me and it was effective enter image description here

cigien
  • 57,834
  • 11
  • 73
  • 112
José
  • 1
  • 1
-1

The above solutions explain clearly what the problem is; when you don't have control over the repo, the best way to submit your code is to create a Fork of the original repo and submit your code to this new repo so later you can push it to the original one.

gogasca
  • 9,283
  • 6
  • 80
  • 125