linuxlab.io
Tutorials▾
  • Linux & networking
    File system, processes, TCP/IP, BGP and OSPF
    →
  • Terraform & IaC
    HCL, state, plan/apply on a LocalStack sandbox
    →
  • Git & GitHub
    Object model, plumbing, branching, GitHub Actions
    →
All tutorials →
PricingAboutSign inCreate account
/
Intro
Lessons
Footer
linuxlab-TutorialsPricingAboutPrivacy & cookies
Copyright © 2026 LinuxLab. All rights reserved.
linuxlab.io
Tutorials▾
  • Linux & networking
    File system, processes, TCP/IP, BGP and OSPF
    →
  • Terraform & IaC
    HCL, state, plan/apply on a LocalStack sandbox
    →
  • Git & GitHub
    Object model, plumbing, branching, GitHub Actions
    →
All tutorials →
PricingAboutSign inCreate account
/
  • Introduction
  • Chapters
  • How it works
  • Lessons
  • Knowledge base
  • Interview prep
home/git/kb/Collaboration/branch-protection

kb/collab ── Collaboration ── intermediate

Branch protection rules

A set of rules that GitHub/GitLab/Bitbucket applies to any attempt to modify a protected branch. Blocks direct pushes, requires a PR with an approval, requires green CI, and blocks force-pushes. Without these rules anyone with write access can overwrite main with a single commit.

view as markdownaka: branch-protection-rules, protected-branch

Branch protection is server-side enforcement against direct changes and force-pushes to a branch. Configure it under Settings -> Branches on GitHub (on GitLab this is "Protected branches"; on Bitbucket, "Branch restrictions"). Without it, a branch differs from any other only by name. With it, a push attempt is checked against the rules and rejected if any rule is violated.

What to enable on main

A minimal set for a working repo:

  • Require a pull request before merging: blocks direct pushes; changes can only land via a merged PR.
  • Require approvals (minimum 1): at least one other team member must approve.
  • Dismiss stale pull request approvals when new commits are pushed: approvals are dismissed after a new commit is pushed. Guards against "got an approval, added five hundred lines, merged."
  • Require status checks to pass: selected CI jobs must be green.
  • Require conversation resolution: all review comments must be resolved.
  • Do not allow bypassing the above: admins follow the rules too. Without this checkbox, protection becomes a suggestion.
  • Allow force pushes and Allow deletions: leave these off. In the UI these are "allow" toggles: turning them on removes the branch's protection against overwrites and deletion.

Optional settings

  • Require linear history: forbids merge commits; only squash or rebase. A matter of team preference.
  • Require signed commits: all commits must be signed (gpg-signing). Useful on security-sensitive repos.
  • Require review from Code Owners: combined with codeowners, blocks merge until an owner of the changed path approves.
  • Restrict who can push: an explicit list of people or teams.

What gets blocked

Without a bypass, a protected branch refuses:

  • git push origin main (direct push)
  • git push --force origin main (force-push)
  • git push origin --delete main (deletion)
  • merging a PR that does not satisfy the rules

Pitfalls

  • Settings -> Branches is only accessible to repo admins. If you are not an admin, only the owner can configure this.
  • Status checks become required by name. If you rename a CI workflow, the old name stays "required" but never runs. Go to branch protection and update it.
  • Protection applies to a pattern, not just a single branch. You can protect release/* as a whole.
  • On GitLab the equivalent is "Protected branches"; on Bitbucket it is "Branch restrictions." The concept is the same; the available options differ slightly.

§ команды

bash
gh api repos/:owner/:repo/branches/main/protection

View the current protection rules via the GitHub API

bash
gh api -X PUT repos/:owner/:repo/branches/main/protection -f required_pull_request_reviews[required_approving_review_count]=1

Programmatically set required approvals=1 via the API

§ см. также

  • codeownersCODEOWNERSThe `.github/CODEOWNERS` file maps paths in the repo to teams or individuals. When a PR touches those paths, the owners are automatically assigned as reviewers. Combined with branch protection, it blocks merge until they approve.
  • pull-requestPull Request (PR)A request to merge a branch into the main branch after passing review and CI. On GitHub/GitLab/Bitbucket it is the standard mechanism for collaborative work. Technically it is not a Git command but a hosting feature built on top of branches and commits.
  • force-pushForce push`git push --force` overwrites the remote history with yours. `git push --force-with-lease` does the same, but refuses if someone pushed there after your last fetch. Always use `--force-with-lease`.
Footer
linuxlab-
Copyright © 2026 LinuxLab. All rights reserved.
Tutorials
Pricing
About
Privacy & cookies