I have master and hotfix_master branches. These are release branches and are protected in Gitlab UI under project settings.

what I'm trying to achieve is, rebase the hotfix_master branch after every production release which happens from master so that if customer raises any bug, we can fix that bug on hotfix_master branch and release to customer.

while doing a proof of concept, I realized is that even though hotfix_master branch is protected, I can still rebase without creating any PR. Is that expected? if yes, what the use of protection? and what should be done to allow rebase only after creating PR?

EDIT 1

This is what I am doing

    - git fetch
    - git checkout hotfix_master
    - git diff --name-only origin/hotfix_master...origin/master
    - git rebase origin/master
    - git status
    - git push

after rebasing , what I see is , all the changes from master are now on hotfix_master. so, where is the question of PR ? why gitlab is not complaining that you haven't raised PR . Please suggest

EDIT 2

CodePudding user response：

"Branch protection" is a feature of GitLab and GitHub. It protects branches in the shared repository from being force-pushed, potentially losing history.

When you have a local clone, you can do whatever you like to your local branches (create them, reset them, merge them, rebase them, create commits, etc.), but you can only perform fast-forward pushes on the "protected branches).

CodePudding user response：

In this setup, if hotfix_master has commits that master does not have, the push (last command in EDIT 1) should fail because of branch protection.

If you want the normal push (which does not allow altering history) to be denied, you have to change the protection settings (Edit 2) "Allowed to push" to a higher level, denying it to anyone who should not do what you demonstrated in Edit 1.

Beside that: Assuming master is the code that is currently in production, you'd usually merge master to other branches to preserve the commit history between branches.