Q40 of 40 · Git
Your team has been using 'commit everything directly to main' for 2 years. How do you lead the transition to a PR-based workflow with branch protection, and what are the biggest risks?
Short answer
Short answer: Introduce the new workflow incrementally: start with a protected `main` that allows direct pushes to admins only, run short-lived branches in parallel for 2 weeks, then remove the admin bypass. The biggest risks are CI coverage gaps (flaky tests block work) and cultural resistance from engineers who see PRs as overhead.
Detail
A workflow transition is a sociotechnical change, not just a Git configuration change. Technical steps without cultural buy-in will fail.
Phase 1 — Baseline (weeks 1-2): before adding any protection, invest in CI quality. Identify and fix all flaky tests. Measure test execution time; if it's > 10 minutes, optimise or parallelise. A slow, flaky CI will make the new workflow feel punishing rather than helpful, creating immediate cultural backlash.
Phase 2 — Soft enforcement (weeks 3-4): enable branch protection with include administrators unchecked — admins can still push directly in emergencies. Require PRs with 1 review and required CI. Communicate the "why": shorter feedback loops, reduced incidents, documented change history. Run lunch-and-learns on interactive rebase, good PR descriptions, and CODEOWNERS.
Phase 3 — Hard enforcement (week 5+): once the team is comfortable and CI is stable, check include administrators. Add the remaining rules (signed commits, linear history). Create runbooks for the emergency bypass procedure (temporarily disable a rule via GitHub API).
Key risks:
- CI coverage gaps: a test suite that doesn't catch regressions means PRs feel like meaningless bureaucracy — engineers will see no benefit.
- Long-lived branches: if engineers avoid the new workflow by opening a single PR with weeks of changes, you've traded a history problem for a review problem. Cap PR size through culture and tooling.
- Knowledge asymmetry: senior engineers adapt quickly; juniors may be blocked by unfamiliar Git commands. Pair-programming sessions and office hours reduce this risk.
- Admin bypass culture: if admins routinely bypass protection "just this once," the rules lose credibility. Log and review all bypasses in retrospectives.
// EXAMPLE
# --- Phase 1: measure CI health before enforcing ---
# Check for flaky tests in the last 30 CI runs
gh run list --workflow=ci.yml --limit 30 --json conclusion,startedAt | jq '[.[] | select(.conclusion=="failure")] | length'
# --- Phase 2: enable protection via GitHub CLI ---
# Require PRs + 1 review + CI — admins still bypass
gh api -X PUT repos/company/repo/branches/main/protection --input protection-config.json
# protection-config.json
# {
# "required_status_checks": { "strict": true, "contexts": ["ci/unit", "ci/integration"] },
# "enforce_admins": false,
# "required_pull_request_reviews": { "required_approving_review_count": 1 },
# "restrictions": null
# }
# --- Phase 3: lock down admins too ---
gh api -X PATCH repos/company/repo/branches/main/protection -f enforce_admins=true
# --- Emergency bypass (break-glass) ---
# Temporarily disable protection for a production hotfix
gh api -X DELETE repos/company/repo/branches/main/protection
# ... push hotfix directly ...
# Re-enable immediately:
gh api -X PUT repos/company/repo/branches/main/protection --input protection-config.json// WHAT INTERVIEWERS LOOK FOR
// Related questions
As a QA lead, how would you configure branch protection rules for `main` and `release/*` branches to enforce quality gates without slowing down the team?
Git
Tell me about a time you had to convince leadership to adopt a new testing approach.
Behavioural
Compare Gitflow and trunk-based development — what are the QA testing implications of each?
Git