CODEWITHSUNDEEP
gitgitlab
ChrisDekker
ChrisDekker

Reputation: 1773

GitLab refuses push to master even though I am the project owner

Running the following:

I have created a project inside GitLab and pushed my code onto there without problems. I am the Project Owner and have the role 'Master' with the project.

Branch 'master' is set as a 'protected branch' by default, allowing only group members with role 'Master' to merge and push to that branch.

Now I made some small changes directly in master that didn't warrant a separate branch.

However, when I commit and push these changes, I get the following error:

D:\Projects\MyProject>git push
Counting objects: 8, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (8/8), done.
Writing objects: 100% (8/8), 731 bytes | 0 bytes/s, done.
Total 8 (delta 7), reused 0 (delta 0)
remote: GitLab: You are not allowed to force push code to a protected branch on this project.
To https://git.****.**/*****/****.git
 ! [remote rejected] master -> master (pre-receive hook declined)
error: failed to push some refs to 'https://git.****.**/*****/****.git'

Not sure what I am doing wrong. I am not an expert on Git, but is this considered a 'force push'? Since that is blocked by all users, including those with role 'master'. If so, how should I be doing changes to the master branch?

It must have something to do with the 'protected branch'. If I remove that, I can push just fine. However, since the 'protected branch' also prevents deleting of the branch and its history, I would like to keep that in place.

Upvotes: 2

Views: 2717

Answers (2)

VonC
VonC

Reputation: 1326646

This should work better with GitLab 13.0 (May 2020)

Enable group-level default branch protection

Previously, the translation of instance-level default branch protection settings down into projects was confusing because, in certain scenarios, it created an unintuitive experience: developers could not push new commits to projects they could create.

This made it difficult for organizations to strike a balance between mitigating risk and allowing carte blanche access to projects for all developers since the workaround required promoting them to Maintainer.

Now, default branch protection can be set at the group level to provide better flexibility for administrators and group owners.

Using a combination of default branch protection and default project creation settings, organizations can find the right mix of autonomy and control, such as using custom default branch protection and allowing only maintainers to create new projects.
This would allow developers to push new commits (not force push or delete a branch) to new projects, but allow maintainers to control project creation.

This group-level configuration of default branch protection can be disabled for organizations requiring more strict controls in place.
By disabling the group-level setting for default branch protection, maintainers can apply more stringent controls on developer access and permissions.

See documentation and issue.

Upvotes: 1

ChrisDekker
ChrisDekker

Reputation: 1773

According to the GitLab issue tracker this is a known incompatibility with Git 2.11 and latest GitLab versions.

https://gitlab.com/gitlab-org/gitlab-ce/issues/25301

Downgrading temporarily to Git 2.10 from source should fix the issue until proper support for Git 2.11+ is built in a future release of GitLab.

Upvotes: 1

Related Questions