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
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/gitResults 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 ... FinishedPossible fixes
(If you can, link to the line of code that might be responsible for the problem)
Не могу понять как исправить ошибку. После гит пуша идет успешная загрузка, но в конце вот эта ошибка:
-
Вопрос заданболее двух лет назад
-
243 просмотра
Очевидно, админ репы запретил пушить в мастер. Только через pull(или merge) request.
Белым по синему же:
You are not allowed to push code to protected branches on this project
Делаете свои изменения в отдельной ветке и создаёте Merge Request
Пригласить эксперта
-
Показать ещё
Загружается…
29 янв. 2023, в 03:07
300000 руб./за проект
29 янв. 2023, в 02:16
700000 руб./за проект
29 янв. 2023, в 01:54
5000 руб./за проект
Минуточку внимания
Я пытаюсь перейти на главную ветку репо, но мне не удается это сделать, поскольку она защищена.
Я пытался заглянуть в настройки проекта и не вижу опции для защищенных веток. Единственный вариант, который я мог видеть — это участники.
remote: GitLab: You are not allowed to push code to protected branches on this project.
To git@gitlab.ins.risk.regn.net:cmd/release.git
! [remote rejected] master -> master (pre-receive hook declined)
error: failed to push some refs to 'git@gitlab.ins.risk.regn.net:cmd/release.git'
В моем репо есть только одна ветка, в которой пока нет содержимого.
Я вижу параметры защищенных веток других моих репо, но не для этого конкретного.
Это новый репо без содержимого и с только веткой по умолчанию.
У меня есть разрешение master.
К сожалению, я не могу загрузить изображение здесь как-то.
Подскажите пожалуйста как протолкнуть код в главную ветку.
8 ответов
Лучший ответ
без содержания в нем до сих пор
Это означает, что ветвь master еще не защищена, потому что в пустом репо ее нет.
Чтобы «Включить / отключить защиту филиалов», необходимо быть главным или владельцем проект GitLab (которым вы являетесь).
Убедиться:
- ваш первый толчок —
git push -u origin master; - удаленный
originссылается на правильный репо (git remote -v); - ваш локальный ключ ssh правильный (
ssh -T git@gitlab.ins.risk.regn.net); - Вы являетесь участником группы
cmd.
9
Community
23 Май 2017 в 12:26
Возможно, мастер ветка открывает защиту. Вам нужно выбрать разработчика, чтобы нажать в настройках ветки защиты.
-2
Depth Y
26 Июл 2018 в 08:46
12/17/2018
1. git push: «ошибка: не удалось отправить некоторые ссылки на»
git push -f: «удаленный отказано»
2. филиал находится в защищенном состоянии и не может быть принужден к работе.
Gitlab - Repository - Branches
3. временно снять ветку защиты.
Gitlab - Settings - Repository - Protected Branches - Unprotect
4. попробуйте снова нажать
git push -f
5. может добавить защиту
17
山茶树和葡萄树
17 Дек 2018 в 03:45
У меня была похожая проблема — конвейер / задание CI / CD для проекта жаловалось на то, что он не может извлечь код из защищенной ветви частного репозитория на автономном экземпляре GitLab.
В моем случае я мог манипулировать репозиториями и извлекать код напрямую с помощью git, потому что у меня были полные права администратора в GitLab. В итоге получается, что GitLab Runner не разрешили клонировать репозиторий, потому что мой пользователь не был прямым членом группы проекта.
0
zorlem
9 Июн 2020 в 13:44
В GitLab некоторые ветки могут быть защищены. По умолчанию только «главный» пользователь может зафиксировать защищенные ветви, а главная ветка защищена по умолчанию.
Вы можете включить и выключить защиту для выбранных веток в настройках проекта (перейдите в проект: «Настройки» -> «Хранилище» -> «Развернуть» в «Защищенные ветки»).
На той же странице настроек вы также можете разрешить разработчикам проталкивать защищенные ветки. Если этот параметр включен, защита будет ограничена отклонением операций, требующих git push —force
4
7wick
9 Янв 2019 в 04:58
Проект: «Настройки» -> «Защищенные ветви» (если вы хотя бы «Мастер» данного проекта).
Затем нажмите «Снять защиту» или «Разработчики могут нажать»
1
aristotll
13 Сен 2018 в 07:17