You are not allowed to push code to protected branches on this project ошибка

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»

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».

Pre GitLab 9.0

Project: «Settings» → «Protected branches» (if you are at least ‘Master’ of given project).

Then click on «Unprotect» or «Developers can push»:

Open


Issue created Sep 21, 2018 by Mislav Orsolic@morsolic

You are not allowed to force push code to a protected branch

Summary

(Summarize the bug encountered concisely)

This is basically the problem:
https://gitlab.com/gitlab-org/gitlab-ce/issues/25301

Steps to reproduce

(How one can reproduce the issue — this is very important)

When we want to push new changes, this error occurs.

Example Project

(If possible, please create an example project here on GitLab.com that exhibits the problematic behaviour, and link to it here in the bug report)

(If you are using an older version of GitLab, this will also determine whether the bug has been fixed in a more recent version)

What is the current bug behavior?

(What actually happens)

After pushing code changes to a reposity, master becomes protected for some reason. Then we need to go to settings repository, protected branches and click unprotect.

What is the expected correct behavior?

(What you should see instead)

Correct behavior — master shouldn’t become protected.

Relevant logs and/or screenshots

(Paste any relevant logs — please use code blocks («`) to format console output,
logs, and code as it’s very hard to read otherwise.)

This started to happen when we upgraded Gitlab server from 11.2.1-ce.0 to 11.2.3-ce.0.

Output of checks

(If you are reporting a bug on GitLab.com, write: This bug happens on GitLab.com)

Results of GitLab environment info

Expand for output related to GitLab environment info

(For installations with omnibus-gitlab package run and paste the output of:
sudo gitlab-rake gitlab:env:info)
(For installations from source run and paste the output of:
sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production)

System information
System:		
Current User:	git
Using RVM:	no
Ruby Version:	2.4.4p296
Gem Version:	2.7.6
Bundler Version:1.16.2
Rake Version:	12.3.1
Redis Version:	3.2.11
Git Version:	2.18.0
Sidekiq Version:5.1.3
Go Version:	unknown

GitLab information
Version:	11.2.3
Revision:	06cbee3
Directory:	/opt/gitlab/embedded/service/gitlab-rails
DB Adapter:	postgresql
URL:		http://gitlab.xx.lan
HTTP Clone URL:	http://gitlab.xx.lan/some-group/some-project.git
SSH Clone URL:	git@gitlab.xx.lan:some-group/some-project.git
Using LDAP:	no
Using Omniauth:	no

GitLab Shell
Version:	8.1.1
Repository storage paths:
- default: 	/var/opt/gitlab/git-data/repositories
Hooks:		/opt/gitlab/embedded/service/gitlab-shell/hooks
Git:		/opt/gitlab/embedded/bin/git

Results of GitLab application Check

Expand for output related to the GitLab application check

(For installations with omnibus-gitlab package run and paste the output of:
sudo gitlab-rake gitlab:check SANITIZE=true)
(For installations from source run and paste the output of:
sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true)
(we will only investigate if the tests are passing)

Checking GitLab Shell ...

GitLab Shell version >= 8.1.1 ? ... OK (8.1.1)
Repo base directory exists?
default... yes
Repo storage directories are symlinks?
default... no
Repo paths owned by git:root, or git:git?
default... yes
Repo paths access is drwxrws---?
default... yes
hooks directories in repos are links: ... 
9/2 ... ok
8/4 ... ok
8/5 ... ok
7/6 ... ok
10/7 ... ok
7/8 ... ok
2/9 ... ok
9/10 ... ok
10/12 ... ok
10/13 ... ok
10/15 ... ok
10/16 ... ok
10/17 ... ok
10/19 ... ok
10/21 ... ok
10/22 ... ok
10/23 ... ok
10/24 ... ok
10/25 ... ok
10/26 ... ok
11/28 ... ok
11/29 ... ok
11/30 ... ok
7/31 ... ok
17/32 ... ok
17/33 ... ok
13/34 ... ok
13/35 ... ok
13/36 ... ok
6/37 ... ok
6/38 ... ok
6/39 ... ok
12/40 ... ok
12/41 ... ok
12/42 ... ok
12/43 ... ok
13/44 ... ok
6/45 ... ok
17/46 ... ok
13/47 ... ok
6/48 ... ok
8/49 ... ok
17/50 ... ok
6/51 ... ok
7/52 ... ok
7/53 ... ok
7/54 ... ok
13/55 ... ok
13/56 ... ok
6/57 ... ok
10/58 ... ok
12/59 ... ok
12/60 ... ok
17/61 ... ok
13/62 ... ok
12/63 ... ok
12/64 ... ok
17/65 ... ok
17/66 ... ok
17/67 ... ok
18/68 ... ok
17/70 ... ok
6/74 ... ok
25/75 ... ok
9/76 ... ok
9/77 ... ok
13/79 ... ok
13/80 ... ok
9/81 ... ok
6/82 ... ok
16/83 ... ok
13/84 ... ok
6/85 ... ok
13/86 ... ok
16/87 ... ok
13/88 ... ok
17/89 ... ok
17/90 ... ok
6/91 ... ok
12/92 ... ok
6/93 ... ok
17/94 ... ok
16/95 ... ok
17/96 ... ok
17/97 ... ok
6/98 ... ok
6/99 ... ok
6/100 ... ok
13/101 ... ok
13/102 ... ok
6/103 ... ok
18/104 ... ok
18/105 ... ok
18/106 ... ok
18/107 ... ok
18/108 ... ok
18/109 ... ok
18/110 ... ok
18/111 ... ok
6/112 ... ok
17/113 ... ok
15/114 ... ok
17/115 ... ok
9/116 ... ok
17/117 ... ok
12/120 ... ok
12/121 ... ok
17/122 ... ok
13/123 ... ok
12/124 ... ok
12/125 ... ok
10/126 ... ok
25/127 ... ok
21/128 ... ok
21/129 ... ok
17/130 ... ok
18/131 ... ok
6/132 ... ok
21/133 ... ok
24/134 ... ok
17/136 ... ok
12/137 ... ok
17/138 ... ok
17/139 ... ok
17/140 ... ok
13/141 ... ok
17/142 ... ok
17/143 ... ok
6/144 ... ok
17/145 ... ok
12/146 ... ok
6/147 ... ok
6/148 ... ok
12/149 ... ok
12/150 ... ok
17/151 ... ok
12/152 ... ok
13/153 ... ok
17/154 ... ok
9/155 ... ok
25/156 ... ok
12/157 ... ok
12/158 ... ok
Running /opt/gitlab/embedded/service/gitlab-shell/bin/check
Check GitLab API access: OK
Redis available via internal API: OK

Access to /var/opt/gitlab/.ssh/authorized_keys: OK
gitlab-shell self-check successful

Checking GitLab Shell ... Finished

Checking Sidekiq ...

Running? ... yes
Number of Sidekiq processes ... 1

Checking Sidekiq ... Finished

Reply by email is disabled in config/gitlab.yml
Checking LDAP ...

LDAP is disabled in config/gitlab.yml

Checking LDAP ... Finished

Checking GitLab ...

Git configured correctly? ... yes
Database config exists? ... yes
All migrations up? ... yes
Database contains orphaned GroupMembers? ... no
GitLab config exists? ... yes
GitLab config up to date? ... yes
Log directory writable? ... yes
Tmp directory writable? ... yes
Uploads directory exists? ... yes
Uploads directory has correct permissions? ... yes
Uploads directory tmp has correct permissions? ... no
  Try fixing it:
  sudo chown -R git /var/opt/gitlab/gitlab-rails/uploads
  sudo find /var/opt/gitlab/gitlab-rails/uploads -type f -exec chmod 0644 {} ;
  sudo find /var/opt/gitlab/gitlab-rails/uploads -type d -not -path /var/opt/gitlab/gitlab-rails/uploads -exec chmod 0700 {} ;
  For more information see:
  doc/install/installation.md in section "GitLab"
  Please fix the error above and rerun the checks.
Init script exists? ... skipped (omnibus-gitlab has no init script)
Init script up-to-date? ... skipped (omnibus-gitlab has no init script)
Projects have namespace: ... 
9/2 ... yes
8/4 ... yes
8/5 ... yes
7/6 ... yes
10/7 ... yes
7/8 ... yes
2/9 ... yes
9/10 ... yes
10/12 ... yes
10/13 ... yes
10/15 ... yes
10/16 ... yes
10/17 ... yes
10/19 ... yes
10/21 ... yes
10/22 ... yes
10/23 ... yes
10/24 ... yes
10/25 ... yes
10/26 ... yes
11/28 ... yes
11/29 ... yes
11/30 ... yes
7/31 ... yes
17/32 ... yes
17/33 ... yes
13/34 ... yes
13/35 ... yes
13/36 ... yes
6/37 ... yes
6/38 ... yes
6/39 ... yes
12/40 ... yes
12/41 ... yes
12/42 ... yes
12/43 ... yes
13/44 ... yes
6/45 ... yes
17/46 ... yes
13/47 ... yes
6/48 ... yes
8/49 ... yes
17/50 ... yes
6/51 ... yes
7/52 ... yes
7/53 ... yes
7/54 ... yes
13/55 ... yes
13/56 ... yes
6/57 ... yes
10/58 ... yes
12/59 ... yes
12/60 ... yes
17/61 ... yes
13/62 ... yes
12/63 ... yes
12/64 ... yes
17/65 ... yes
17/66 ... yes
17/67 ... yes
18/68 ... yes
17/70 ... yes
6/74 ... yes
25/75 ... yes
9/76 ... yes
9/77 ... yes
13/79 ... yes
13/80 ... yes
9/81 ... yes
6/82 ... yes
16/83 ... yes
13/84 ... yes
6/85 ... yes
13/86 ... yes
16/87 ... yes
13/88 ... yes
17/89 ... yes
17/90 ... yes
6/91 ... yes
12/92 ... yes
6/93 ... yes
17/94 ... yes
16/95 ... yes
17/96 ... yes
17/97 ... yes
6/98 ... yes
6/99 ... yes
6/100 ... yes
13/101 ... yes
13/102 ... yes
6/103 ... yes
18/104 ... yes
18/105 ... yes
18/106 ... yes
18/107 ... yes
18/108 ... yes
18/109 ... yes
18/110 ... yes
18/111 ... yes
6/112 ... yes
17/113 ... yes
15/114 ... yes
17/115 ... yes
9/116 ... yes
17/117 ... yes
12/120 ... yes
12/121 ... yes
17/122 ... yes
13/123 ... yes
12/124 ... yes
12/125 ... yes
10/126 ... yes
25/127 ... yes
21/128 ... yes
21/129 ... yes
17/130 ... yes
18/131 ... yes
6/132 ... yes
21/133 ... yes
24/134 ... yes
17/136 ... yes
12/137 ... yes
17/138 ... yes
17/139 ... yes
17/140 ... yes
13/141 ... yes
17/142 ... yes
17/143 ... yes
6/144 ... yes
17/145 ... yes
12/146 ... yes
6/147 ... yes
6/148 ... yes
12/149 ... yes
12/150 ... yes
17/151 ... yes
12/152 ... yes
13/153 ... yes
17/154 ... yes
9/155 ... yes
25/156 ... yes
12/157 ... yes
12/158 ... yes
Redis version >= 2.8.0? ... yes
Ruby version >= 2.3.5 ? ... yes (2.4.4)
Git version >= 2.9.5 ? ... yes (2.18.0)
Git user has default SSH configuration? ... yes
Active users: ... 5

Checking GitLab ... Finished

Possible fixes

(If you can, link to the line of code that might be responsible for the problem)

Problem Description:

I am trying to push to master branch of a repo and I am failing to do so, since it is protected.
I tried to look into the project settings and do not see any option for protected branches. The only option I could see is members.

remote: GitLab: You are not allowed to push code to protected branches on this project.
To [email protected]:cmd/release.git
 ! [remote rejected] master -> master (pre-receive hook declined)
error: failed to push some refs to '[email protected]:cmd/release.git'

My repo has only one branch, with no contents in it so far.
I do see protected branches options of my other Repos but not for this specific one.
It is a new repo with no contents and with only default branch.
I have the master permission.
Unfortunately I am not able to upload the image here somehow.

Please suggest how to push code to master branch.

Solution – 1

with no contents in it so far

That means there is no master branch to protect yet, because the empty repo does not has one.

To “Enable/disable branch protection”, you need to be Master or Owner of the GitLab project (which you are).

Make sure:

• your first push is a git push -u origin master;
• the remote origin does reference the right repo (git remote -v);
• your local ssh key is the right one (ssh -T [email protected]);
• you are a member of the cmd group.

Solution – 2

It means that you may have a master branch, but it is protected in project settings. See:

how to fix: you are not allowed to push code to protected branches on this project or https://gitlab.com/gitlab-com/support-forum/issues/207.

In order to access project settings and unprotect the branch, you need to have sufficient rights.

Solution – 3

Project: “Settings” -> “Protected branches” (if you are at least ‘Master’ of given project).

Then click on “Unprotect” or “Developers can push”

Solution – 4

Perhaps the master branch opens the protection. You need to select the developer to push in the protection branch settings.

Solution – 5

12/17/2018

1. git push: “error: failed to push some refs to”

git push -f: “remote rejected”

2. the branch is in a protected state and cannot be forced to operate.

Gitlab - Repository - Branches

3. temporarily remove branch protection.

Gitlab - Settings - Repository - Protected Branches - Unprotect

4. try pushing again

git push -f

5. may add protection

Solution – 6

In GitLab some branches can be protected. By default only ‘master’ user can commit to protected branches and master branch is protected by default.

You can turn on and off protection on selected branches in Project Settings (Go to project: “Settings” -> “Repository” -> “Expand” on “Protected branches” ).

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

Solution – 7

Settings>Repo>Expand.. worked for me
Few branches could be secured. Keep in mind the master branch is default protected. As a matter of course the master will be able to commit to protected branches.

Check out: https://gitlab.com/gitlab-org/gitlab-foss/-/issues/51741

Solution – 8

I had a similar issue – a CI/CD pipeline/job for a project was complaining that it can’t pull the code from a protected branch of a private repository on a self-hosted GitLab instance.

In my case I was able to manipulate the repositories and pull code directly with git because I had full administrative privileges in GitLab. In the end it turns out that GitLab Runner was not allowed to clone the repository because my user was not a direct member of the project group.

Solution – 9

I know it’s a little old, but for me, remote was set with a prefixed user that a devops made to deploy, so I had to change remote url to don’t use the username it was set, or you can change to yours.

Solution – 10

We decided to push to a different branch and then create a merge request from that different branch into main using the GitLab UI.

git push -fu origin differentbranch  

Our reason for doing this is that locking down branches like main is a good policy. We do not want to weaken that good policy by allowing manual overrides to it.

The merge request process in the GitLab UI only took a few seconds, so that our approach might even be faster than the other approaches offered by other answers to this old OP.

Solution 1

with no contents in it so far

That means there is no master branch to protect yet, because the empty repo does not has one.

To «Enable/disable branch protection», you need to be Master or Owner of the GitLab project (which you are).

Make sure:

• your first push is a git push -u origin master;
• the remote origin does reference the right repo (git remote -v);
• your local ssh key is the right one (ssh -T [email protected]);
• you are a member of the cmd group.

Solution 2

12/17/2018

1. git push: «error: failed to push some refs to»

git push -f: «remote rejected»

2. the branch is in a protected state and cannot be forced to operate.

Gitlab - Repository - Branches

3. temporarily remove branch protection.

Gitlab - Settings - Repository - Protected Branches - Unprotect

4. try pushing again

git push -f

5. may add protection

Solution 3

In GitLab some branches can be protected. By default only ‘master’ user can commit to protected branches and master branch is protected by default.

You can turn on and off protection on selected branches in Project Settings (Go to project: «Settings» -> «Repository» -> «Expand» on «Protected branches» ).

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