Bird
Raised Fist0
Gitdevops~30 mins

Branch protection rules in Git - Mini Project: Build & Apply

Choose your learning style10 modes available
Setting Up Branch Protection Rules in Git
📖 Scenario: You are working on a team project using Git. To keep the main branch safe from accidental changes, you want to set up branch protection rules. These rules will help prevent direct pushes and require pull requests for changes.
🎯 Goal: Learn how to create a branch protection rule for the main branch using GitHub CLI commands to enforce safe collaboration practices.
📋 What You'll Learn
Create a branch protection rule for the main branch
Require pull request reviews before merging
Prevent direct pushes to the main branch
Enable status checks to pass before merging
💡 Why This Matters
🌍 Real World
Branch protection rules help teams avoid mistakes by enforcing code review and testing before changes reach important branches like main or master.
💼 Career
Understanding how to set branch protection rules is essential for DevOps engineers and developers working in teams to maintain code quality and secure collaboration.
Progress0 / 4 steps
1
Create a GitHub repository called demo-repo
Use the GitHub CLI command gh repo create demo-repo --public --confirm to create a new public repository named demo-repo.
Git
Hint

Use gh repo create with the repository name demo-repo, make it public, and confirm automatically.

2
Set a branch protection rule variable for the main branch
Create a variable called branch_name and set it to the string main to specify the branch you want to protect.
Git
Hint

Use branch_name="main" to store the branch name.

3
Apply branch protection rules to require pull request reviews and prevent direct pushes
Use the GitHub CLI command gh api to create a branch protection rule on the repository demo-repo for the branch stored in branch_name. Require pull request reviews, prevent direct pushes, and require status checks to pass before merging.
Git
Hint

Use gh api --method PUT with the correct endpoint and flags to set protection rules.

4
Verify the branch protection rules are applied
Use the GitHub CLI command gh api to get the branch protection settings for the main branch in demo-repo and print the output.
Git
Hint

Use gh api /repos/:owner/demo-repo/branches/$branch_name/protection to fetch and print the protection settings.

Practice

(1/5)
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
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard