Branch protection is a configurable set of rules, applied to a specific branch (most commonly main or master), that restrict how changes can reach it. Instead of allowing direct pushes from anyone, a protected branch might require that changes go through a pull request, pass automated tests, and receive at least one approving review before they’re allowed in. It’s a feature of the hosting platform — GitHub calls it “branch protection rules,” GitLab calls it “protected branches” — not something built into Git’s own command-line tool.

Picture a real scenario: a five-person engineering team ships a mobile app. Early on, anyone could push straight to main, and one Friday afternoon, a rushed, untested change broke the login flow for every user until Monday morning. After that incident, the team enabled branch protection on main: no direct pushes allowed, every change must come through a pull request, at least one teammate must approve it, and the automated test suite must pass first. The same kind of mistake became structurally much harder to make again — not because anyone got more careful, but because the platform itself now enforces the safety net.

Because branch protection lives on the hosting platform’s side, the enforcement happens at the server, at the exact moment someone attempts to change the branch — not inside Git’s own logic. Here’s the sequence of what actually happens.

flowchart TD
    A["Developer opens\npull request"] --> B{"Direct push\nto main?"}
    B -->|"Blocked by rule"| Z["Rejected instantly"]
    B -->|"Via pull request"| C{"Required\napprovals met?"}
    C -->|"No"| D["Merge button disabled"]
    C -->|"Yes"| E{"Status checks\n(tests) passing?"}
    E -->|"No"| D
    E -->|"Yes"| F{"Branch up to date\nwith main?"}
    F -->|"No"| G["Must update branch\nfirst"]
    F -->|"Yes"| H["Merge allowed"]
    

Notice how each gate is independent — a pull request can have plenty of approvals but still be blocked because the test suite is failing, or vice versa. This layered design is deliberate: it lets teams enforce multiple, unrelated types of safety (human review, automated correctness, up-to-date code) simultaneously, without any single rule being a single point of failure.

Hosting platforms offer a menu of individual rules that can be combined freely. Here are the ones you’ll encounter in almost every professional repository.

• Start with the essentials. Require pull requests and at least one approval on main — this alone prevents the vast majority of accidental breakages.
• Add required status checks as your test suite matures. Once automated tests are reliable, require them to pass before merge is allowed.
• Extend protection to release branches too. Any branch that deploys to production or represents a shipped version deserves the same guardrails as main.
• Build in a documented emergency path. Even strict teams need a clearly defined, auditable way to bypass rules for genuine production emergencies — without quietly disabling protection altogether.
• Review protection rules periodically. As team size and tooling change, revisit whether the rules still match the team’s actual workflow and risk tolerance.