Skip to content

Quiz: Git Workflows & Branching Strategies

← Back to quiz index

10 questions

L1 (3 questions)

1. Which Git workflow uses environment branches (staging, production) to model the deployment pipeline?

Show answer GitLab Flow *GitLab Flow introduces environment branches where code flows downstream (main -> staging -> production). GitHub Flow has no environment branches, and GitFlow uses release branches, not environment branches.*

2. What does the FAST mnemonic stand for when choosing a Git workflow?

Show answer Frequency, Active versions, Stage gates, Team size *FAST helps you choose a workflow by evaluating deploy Frequency, number of Active supported versions, whether you have Stage gates (staging/prod), and Team size.*

3. In release branching, what is the correct order for applying a fix?

Show answer Fix on main first, then cherry-pick backward to each affected release branch *"Fix forward, port backward." Always fix on main (the newest code) first, then backport to release branches. This ensures the fix is never accidentally lost in future releases.*

L2 (7 questions)

1. Which Git workflow is most appropriate for a SaaS team deploying 10 times per day with strong CI/CD and feature flag infrastructure?

Show answer Trunk-Based Development *Trunk-based development is designed for teams with high deploy frequency, strong CI, and feature flags. GitFlow would add unnecessary ceremony for a team deploying this often.*

2. In GitFlow, what is the most commonly forgotten step when creating a hotfix?

Show answer Merging the hotfix branch back to develop *The hotfix must be merged to BOTH main AND develop. Forgetting the develop merge means the fix regresses on the next release cut from develop.*

3. What is the main disadvantage of squash-merging all PRs?

Show answer It loses git bisect granularity within the squashed commit *Squash merge combines all PR commits into one. git bisect can only narrow to the PR level, not individual changes. A large squash commit with hundreds of lines cannot be further bisected.*

4. Why is force-pushing a shared branch dangerous?

Show answer It rewrites commit SHAs, orphaning commits that teammates have already pulled *Force-push rewrites commit SHAs. Anyone who fetched the old SHAs now has orphaned commits. Their next pull creates duplicate commits, phantom conflicts, or silently lost work.*

5. What is cherry-pick drift?

Show answer When fixes are cherry-picked to some release branches but not others, causing inconsistent bug-fix coverage *Cherry-pick drift occurs when fixes land on some release branches but are missed on others (or on main). Over time, different branches have different bug fixes, and users on older versions hit bugs that were fixed elsewhere.*

6. When migrating from GitFlow to trunk-based development, what prerequisites must be met before deleting the develop branch?

Show answer CI must run in under 15 minutes, test coverage must be above 80%, and feature flag infrastructure must be ready *Without fast CI, good test coverage, and feature flags, trunk-based development will result in a perpetually broken main branch. These are prerequisites, not nice-to-haves.*

7. A team using GitHub Flow has a feature branch that is 2 weeks old with 200+ lines of merge conflicts. What is the root cause?

Show answer The branch lived too long without merging main back into it *Merge conflict probability grows exponentially with branch lifetime. A 2-week-old branch in an active team will have massive divergence. The fix is merging main into feature branches daily and keeping branches under 3 days.*