Why bother with protected branches

If you enjoy debugging mysterious production surprises at 3 a m then skip this guide. For the rest of us here is how to use GitLab protected branches and branch permissions to keep the repository sane. This is about preventing accidental pushes, enforcing code review, and making your CI actually mean something.

Create a feature branch properly

Good branch names save lives and future apologies. Make a local branch with a clear name then push it to the remote. Minimal example that actually works with git.

git checkout -b feature/awesome
git push -u origin feature/awesome

Pick names that reflect the purpose and not your mood. feature, fix, hotfix, and chore are useful prefixes in a team setting.

Protect the branch in project settings

Go to Settings > Repository in your GitLab project. Under protected branches add either a specific branch name or a pattern for multiple branches. Protecting main or release branches prevents direct pushes and forces people to use merge requests.

Set push and merge roles that make sense

Permissions are simple but powerful. Decide who can push and who can merge. Typical options look like this

• Allow Maintainers to push when you need tight control
• Allow Developers to create merge requests and run pipelines
• Restrict merges to people who review code or to an approval group

If you are paranoid in a professional way only allow Maintainers to push to main and require merge requests for everyone else. If you trust your developers let them open MRs and enforce approvals and CI before merge.

Test access with realistic roles

Before rolling this out to the whole team create two test accounts that mirror real roles. Give one Developer access and one Guest access and then try to push from each account. You want to see permission denied when someone without rights tries a direct push. That is the whole point.

Use merge requests and require approvals

Require merge requests for protected branches and enable approval rules in the MR settings. Make pipelines mandatory so the CI must pass before any merge goes through. Merge requests give you a traceable audit trail and enforce code review workflows.

• Enable required approvals for critical branches
• Require a successful pipeline before merge to protect production
• Use code owners for automatic approval rules when appropriate

Quick checklist for a sane setup

• Create clear branch naming conventions
• Protect main and release branches in repository settings
• Assign push and merge permissions according to your trust model
• Test with role based accounts so you do not learn by accident
• Require merge requests and passing CI before merge

Follow these steps and your GitLab branch permissions will actually help you ship code instead of creating mystery outages. You will still have bugs, but at least they will be your bugs with a proper audit trail and an angry Slack thread to match.