Developer unable to push to protected branch after git reset

Question

Can anyone explain why a member of my team is unable to push changes to the master branch (changes that will revet the repo back a few commits) after committing this git reset command:

git reset --hard (previous commit SHA)

This is the error that was received after attempting git push:

 ! [rejected]            master -> master (non-fast-forward)
error: failed to push some refs to '[email protected]:xxx/xxxx.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

The branch, master, is protected so that only "Developers + Maintainers" can push to it.

My team mate is a member of the Gitlab group in question with "Developer" privileges and has had no issue pushing to the remote repo before. I have Maintainer privileges and also was not able to push to the protected branch and received the same error.

To work around the issue I removed the branch protection and he was able to force push the changes (git push -f). Does anyone know why this operation fails on a protected branch?

Answer 1

You can try allowing force push / deletions from github repo 'settings'

repository => settings => branches => add rules

Answer 2

As you've figured out, you can't force push to a protected branch on GitLab.
From GitLab documentation:

By default, a protected branch does four simple things:

• It prevents anyone from force pushing to the branch.

So your workaround is the solution here: unprotect -> force-push -> protect

Update

GitLab added new setting to enable force push to protected:

• Navigate to your project’s Settings > Repository.
• Expand Protected branches, and scroll to Protect a branch.
• To allow all users with push access to force push, toggle the Allow force push slider.

GitLab now enabled force push to protected branch on GitLab.com.
On self-managed instances, admins can opt to disable it, so you needs to check with your admin.
Check out more details here