Branch protection rules in Git - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the command to get branch protection rules for a branch in a GitHub repository.

Git

gh api repos/:owner/:repo/branches/:branch/[1]

Drag options to blanks, or click blank then click option'

Abranches

Blist

Cprotection

Drules

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'list' instead of 'protection' causes an invalid API call.

Using 'branches' repeats the resource and is incorrect.

The correct endpoint to get branch protection details is protection after the branch name.

2fill in blank

medium

Complete the YAML snippet to require pull request reviews before merging.

Git

required_pull_request_reviews:
  required_[1]: 1

Drag options to blanks, or click blank then click option'

Aapproving_review_count

Breviews

Cchecks

Dstatuses

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'reviews' instead of 'approving_review_count' causes the rule to not enforce approvals.

Using 'checks' or 'statuses' relates to CI, not reviews.

The key required_approving_review_count enforces that a certain number of approvals are needed before merging.

3fill in blank

hard

Fix the error in the branch protection rule to enforce status checks before merging.

Git

required_status_checks:
  strict: [1]

Drag options to blanks, or click blank then click option'

Afalse

Btrue

CTRUE

DFalse

Attempts:

3 left

💡 Hint

Common Mistakes

Using uppercase 'True' or 'FALSE' causes YAML parsing errors.

Using 'False' disables the strict check.

The YAML boolean value must be lowercase true to be valid and enforce strict status checks.

4fill in blank

hard

Fill both blanks to create a branch protection rule that requires signed commits and disallows force pushes.

Git

require_signed_commits: [1]
allow_force_pushes: [2]

Drag options to blanks, or click blank then click option'

Atrue

Bfalse

Cenabled

Ddisabled

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'enabled' or 'disabled' instead of booleans causes config errors.

Setting both to true disables some protections unintentionally.

Setting require_signed_commits to true requires signed commits. allow_force_pushes set to false disallows force pushes.

5fill in blank

hard

Fill all three blanks to define a branch protection rule that requires linear history, status checks, and no force pushes.

Git

allow_force_pushes: [1]
required_linear_history: [2]
required_status_checks:
  strict: [3]

Drag options to blanks, or click blank then click option'

Afalse

Btrue

CTrue

DFalse

Attempts:

3 left

💡 Hint

Common Mistakes

Using uppercase booleans causes YAML errors.

Allowing force pushes breaks branch protection.

Force pushes are disallowed by setting allow_force_pushes to false. Linear history and strict status checks are enabled with true.

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