Branch protection rules in Git repositories help teams maintain code quality and control. What is the main goal of these rules?
Think about how teams avoid mistakes on main branches.
Branch protection rules stop direct pushes or force pushes to critical branches, requiring reviews or passing tests first.
Using GitHub CLI, you run the command to list branch protection rules for the 'main' branch. What output do you expect?
gh api repos/owner/repo/branches/main/protection
Think about what a successful API call returns.
The command returns JSON showing the protection rules like required status checks and review counts.
You want to enforce that pull requests to 'main' must pass tests before merging. Which YAML snippet correctly configures this?
Which event triggers the workflow for pull requests targeting 'main'?
Option C triggers on pull requests to 'main', running tests before merging. Others either trigger on push or wrong branches.
You try to force push changes to a protected branch but get an error. What is the most likely reason?
Think about why force pushing might be blocked on important branches.
Force pushes rewrite history and can cause data loss, so branch protection rules block them on protected branches.
Arrange the steps to correctly set up branch protection rules that require pull request reviews and passing status checks before merging.
Think about selecting the branch first, then defining checks and reviews, then saving.
You first select the branch, then specify required status checks, enable review requirements, and finally save the settings.