Branch protection rules in Git - Commands & Configuration

Introduction

Branch protection rules help keep important branches safe by preventing accidental changes. They stop direct pushes or deletions and require reviews before changes are added.

When you want to stop team members from accidentally deleting the main branch.

When you want to make sure every change to the main branch is reviewed by someone else.

When you want to prevent force pushes that could overwrite history on important branches.

When you want to require passing tests before merging code into a shared branch.

When you want to keep release branches stable and controlled.

Commands

Rename the current branch to 'main' to use a standard protected branch name.

Terminal

git branch -m main

Expected Output

No output (command runs silently)

Push the 'main' branch to the remote repository and set it as the default upstream branch.

Terminal

git push -u origin main

Expected Output

Enumerating objects: 5, done.

Counting objects: 100% (5/5), done.

Delta compression using up to 8 threads

Compressing objects: 100% (3/3), done.

Writing objects: 100% (5/5), 450 bytes | 450.00 KiB/s, done.

Total 5 (delta 0), reused 0 (delta 0), pack-reused 0

To https://github.com/username/repository.git

 * [new branch]      main -> main

Branch 'main' set up to track remote branch 'main' from 'origin'.

→

-u - Sets upstream tracking for the branch

Delete a feature branch from the remote repository to keep branches clean after merging.

Terminal

git push origin --delete feature-branch

Expected Output

To https://github.com/username/repository.git

 - [deleted]         feature-branch

→

--delete - Deletes the specified remote branch

Mark the local repository directory as safe to avoid permission errors when running Git commands.

Terminal

git config --global --add safe.directory /home/user/myrepo

Expected Output

No output (command runs silently)

→

--global - Apply config globally for the user

Key Concept

If you remember nothing else from branch protection, remember: protect important branches by requiring reviews and blocking direct pushes.

Common Mistakes

Trying to enforce branch protection only with local Git commands.

Branch protection rules are set on the remote repository platform (like GitHub), not locally.

Use the repository hosting service's settings to configure branch protection rules.

Pushing directly to the main branch without a pull request when protection is enabled.

Protected branches block direct pushes to prevent unreviewed changes.

Create a feature branch, make changes, then open a pull request for review before merging.

Summary

Rename your main branch to a standard name like 'main' for easier protection.

Push branches to the remote repository and set upstream tracking.

Delete remote branches after merging to keep the repository clean.

Branch protection rules must be set on the remote platform, not locally.

Practice

1. What is the main purpose of branch protection rules in Git repositories?

easy

A. To prevent direct changes to important branches without review or checks

B. To delete branches automatically after merging

C. To speed up the cloning process of the repository

D. To allow anyone to push changes without restrictions

Solution

1. Step 1: Understand branch protection rules

   Branch protection rules are designed to keep important branches safe by enforcing rules like requiring reviews or passing tests before changes can be merged.

2. Step 2: Identify the correct purpose

   Options A, B, and D describe unrelated or incorrect behaviors. Only To prevent direct changes to important branches without review or checks correctly describes the purpose of branch protection rules.

3. Final Answer:

   To prevent direct changes to important branches without review or checks -> Option A

4. Quick Check:

   Branch protection = prevent unsafe direct changes [OK]

Hint: Branch protection means safe branches, no direct unsafe changes [OK]

Common Mistakes:

• Thinking branch protection deletes branches
• Confusing branch protection with performance features
• Assuming branch protection allows unrestricted pushes

2. Which of the following is the correct way to enable branch protection for the main branch on GitHub via the web interface?

easy

A. Create a file named branch-protect.yml in the root directory

B. Run git protect main in the terminal

C. Go to Settings > Branches > Add rule > Specify 'main' > Select protections > Save

D. Push a branch named protected/main to enable protection

Solution

1. Step 1: Know how to set branch protection on GitHub

   Branch protection rules are set in the repository's Settings under Branches by adding a rule for the branch name and selecting protections.

2. Step 2: Evaluate options

   Go to Settings > Branches > Add rule > Specify 'main' > Select protections > Save describes the correct web interface steps. Options B, C, and D are invalid commands or methods not supported by GitHub.

3. Final Answer:

   Go to Settings > Branches > Add rule > Specify 'main' > Select protections > Save -> Option C

4. Quick Check:

   GitHub branch protection set via Settings > Branches [OK]

Hint: Branch protection is set in repo Settings under Branches [OK]

Common Mistakes:

• Trying to use git CLI commands that don't exist
• Assuming config files control branch protection
• Thinking branch protection is automatic on branch creation

3. Given this branch protection rule requiring pull request reviews before merging, what happens if a user tries to push directly to the protected branch?

Rule: Require pull request reviews before merging

medium

A. The push is rejected with an error message

B. The push succeeds without any checks

C. The branch is automatically deleted

D. The push creates a new branch instead

Solution

1. Step 1: Understand the rule effect

   Requiring pull request reviews means direct pushes to the branch are blocked to enforce code review before changes.

2. Step 2: Predict the push behavior

   Because direct pushes are blocked, the push attempt will be rejected with an error message. Options A, B, and C are incorrect behaviors.

3. Final Answer:

   The push is rejected with an error message -> Option A

4. Quick Check:

   Require review blocks direct push = push rejected [OK]

Hint: Require review means no direct push allowed [OK]

Common Mistakes:

• Assuming push silently creates new branch
• Thinking push succeeds without review
• Believing branch gets deleted on push

4. A developer sets a branch protection rule to require status checks before merging, but merges are still allowed without passing checks. What is the likely cause?

medium

A. The developer forgot to push the branch

B. The status checks are not selected/enabled in the branch protection settings

C. The repository has no branches

D. The branch protection rules only apply to forks

Solution

1. Step 1: Analyze the protection rule setup

   Requiring status checks means you must select which checks must pass in the branch protection settings.

2. Step 2: Identify why merges bypass checks

   If merges happen without passing checks, it usually means the required checks were not properly selected or enabled in the settings.

3. Final Answer:

   The status checks are not selected/enabled in the branch protection settings -> Option B

4. Quick Check:

   Missing selected checks = merges bypass checks [OK]

Hint: Enable and select status checks in protection settings [OK]

Common Mistakes:

• Assuming branch protection applies only to forks
• Thinking pushing branch affects protection
• Ignoring the need to select specific status checks

5. You want to protect the release branch so that only team leads can push directly, and everyone else must use pull requests with reviews. Which branch protection settings should you apply?

hard

A. Require status checks but allow anyone to push directly

B. Enable 'Require signed commits' only

C. Disable all protections and trust the team

D. Enable 'Restrict who can push' to team leads and require pull request reviews for others

Solution

1. Step 1: Understand the requirement

   The goal is to allow only team leads to push directly and force others to use pull requests with reviews.

2. Step 2: Choose correct settings

   Enabling 'Restrict who can push' to team leads limits direct pushes to them. Requiring pull request reviews ensures others must use PRs. Options B, C, and D do not meet both conditions.

3. Final Answer:

   Enable 'Restrict who can push' to team leads and require pull request reviews for others -> Option D

4. Quick Check:

   Restrict push + require reviews = controlled direct push [OK]

Hint: Restrict push to leads + require reviews for others [OK]

Common Mistakes:

• Only requiring signed commits without push restrictions
• Disabling protections and trusting team
• Allowing anyone to push directly with status checks only