Branch Protections and Permissions
Branch protection rules allow teams to control how and when branches can be modified. These rules are commonly used to safeguard key branches like main, master, or release.
1. Why Use Branch Protections?
- Prevent force pushes or accidental deletion
- Require status checks to pass before merging
- Enforce code review via pull requests
- Maintain a clean and secure Git history
2. Common Protection Rules
a. Require Pull Requests
- Prevents direct pushes to the branch.
- Ensures changes are reviewed and tested before merging.
b. Require Reviewers
- Mandates approval from one or more team members.
- Often combined with status checks or CI.
c. Status Checks
- Requires CI/CD pipelines or linters to pass before merge.
- Helps prevent broken builds from being introduced.
d. Restrict Who Can Push
- Only selected users or teams can push to the branch.
- Useful for enforcing release workflows or maintainer-only access.
e. Require Linear History
- Prevents merge commits and enforces rebase strategy.
- Keeps history clean and linear.
3. Enabling Protections (GitHub Example)
GitHub > Settings > Branches > Add Rule
- Choose branch name pattern (e.g.,
main). - Check protection rules you want (e.g., Require pull requests, Require status checks).
- Optionally add push restrictions and reviewer settings.
4. Permissions and Roles
On GitHub/GitLab, access control is role-based.
| Role | Permissions |
|---|---|
| Admin | Full control, can bypass rules if allowed |
| Maintainer | Merge pull requests, manage issues, approve reviews |
| Developer | Push to non-protected branches, create pull requests |
| Guest | Read-only access, can fork and view code |
Summary
| Protection Feature | Benefit |
|---|---|
| Pull Request Requirement | Enforces review before merging |
| Reviewer Requirement | Requires team approvals |
| Status Checks | Prevents merging broken builds |
| Push Restrictions | Controls who can make changes |
| Linear History | Enforces rebase, keeps history clean |