Git Workflows¶
38 cards — 🟢 10 easy | 🟡 15 medium | 🔴 7 hard
🟢 Easy (10)¶
1. What is trunk-based development?
Show answer
Everyone commits to main (the trunk). Feature branches live less than one day. Incomplete features are hidden behind feature flags, not long-lived branches.2. How does GitHub Flow differ from trunk-based development?
Show answer
GitHub Flow uses feature branches with pull requests into main. Branches can live 1-3 days (vs <1 day in TBD). Both use a single main branch with no develop or release branches.3. What are the five branch types in GitFlow?
Show answer
Develop, Feature, Release, Hotfix, and Main. Mnemonic: DFRHM. Main holds production releases, develop is the integration branch, features branch from develop, releases stabilize code, hotfixes patch production.4. What is the core principle of GitLab Flow?
Show answer
Code flows one direction through environment branches: main -> staging -> production. You never commit directly to environment branches — you merge from upstream. Mnemonic: "Water flows downhill."5. When should you use release branching?
Show answer
When you support multiple released versions simultaneously (e.g., PostgreSQL 14/15/16/17). Each release branch is a promise to patch that version until its EOL date. Mnemonic: "Branch per promise."6. What are the three main merge strategies in Git?
Show answer
1) Merge commit (--no-ff): preserves full branch history.2) Rebase: replays commits for linear history.
3) Squash merge: combines all branch commits into one. Mnemonic: MRS — Merge, Rebase, Squash.
7. Why are feature flags essential for trunk-based development?
Show answer
Feature flags decouple deployment from release. Code ships to production on every commit but new features are hidden behind flags until ready. Without flags, unfinished features would be visible to users.8. Why is branch protection the most important workflow enforcement mechanism?
Show answer
Without branch protection, your workflow is just a suggestion. Any developer can push directly to main, skip CI, or force-push. Branch protection makes the rules mandatory, not optional.9. What is the deployment model in GitHub Flow?
Show answer
Main is always deployable. Deployments happen from main — either automatically on merge or on a schedule. There are no release branches. Rollback = revert the merge commit.10. Who created GitFlow and when?
Show answer
Vincent Driessen published "A Successful Git Branching Model" on January 5, 2010. In 2020, he added a note saying GitFlow is NOT suitable for teams practicing continuous delivery.🟡 Medium (15)¶
1. What CI/CD pattern does trunk-based development use?
Show answer
Push to main triggers the full test suite, then auto-deploys to production. Feature flags control visibility. There is one pipeline for one branch. Rollback = turn off the flag or deploy a previous commit.2. What is the most common GitFlow hotfix mistake?
Show answer
Forgetting to merge the hotfix to BOTH main AND develop. If you only merge to main, the fix is missing in develop and will regress on the next release. Mnemonic: "Hotfix hits home AND dev."3. Why does squash-merging reduce git bisect effectiveness?
Show answer
Squash merge combines all PR commits into one. git bisect can only narrow to the PR level, not the individual change. A squash commit with 847 lines across 23 files cannot be further bisected.4. Why should you never rebase a shared branch?
Show answer
Rebase rewrites commit SHAs. Anyone who pulled the old branch now has orphaned commits. Their next pull creates duplicate commits, phantom conflicts, or silently lost work. Rule: "Rebase your own, merge everyone's."5. What is cherry-pick drift and why is it dangerous?
Show answer
When fixes are cherry-picked to some release branches but not others, or not backported to main. Over time, different branches have different bug fixes. Users on older versions hit bugs that were fixed elsewhere.6. What four factors determine which Git workflow to choose?
Show answer
FAST: Frequency (how often you deploy), Active versions (how many you support), Stage gates (do you have staging/prod promotion), Team size. Walk through these and the workflow picks itself.7. At what branch age does merge conflict probability become critical?
Show answer
Beyond 3 days, conflict probability rises sharply with team size. A 2-day branch in a 5-person team has ~10% conflict chance. A 2-week branch has ~80%. Rule: "Three days? Three-alarm fire."8. Why is GitFlow a poor fit for teams deploying multiple times per day?
Show answer
GitFlow adds ceremony (develop branch, release branches, back-merges) designed for scheduled releases. For continuous delivery, this overhead provides no benefit — you spend more time on branch management than writing code.9. What is the difference between tag-based and branch-based releases?
Show answer
Tag-based: tag a commit on main, CI builds artifacts from the tag. Used in TBD/GitHub Flow. Branch-based: cut a release/X.Y branch from develop, stabilize, merge to main, tag. Used in GitFlow.10. What are stacked PRs and when should you use them?
Show answer
A chain of PRs where each builds on the previous: PR#1 → main, PR#2 → PR#1, PR#3 → PR#2. Used for large features that are too big for one PR. Reviewed and merged bottom-up.11. What is --force-with-lease and when should you use it?
Show answer
--force-with-lease force-pushes only if nobody else has pushed since your last fetch. It prevents overwriting others' work. Use it instead of --force when you must update a remote branch after a rebase.12. What is the first step when migrating from GitFlow to trunk-based?
Show answer
Assessment: verify CI runs in <15 minutes, test coverage is >80%, and the team understands feature flags. Do not kill the develop branch until your CI and test infrastructure can protect main.13. What happens if you merge directly to the production branch in GitLab Flow?
Show answer
You bypass staging, skip integration testing, and create a state where production has code that staging does not. Staging is no longer a reliable pre-production environment. Fix: enforce promotion rules with branch protection.14. How do you revert a feature that was merged with a merge commit vs squash-merged?
Show answer
Merge commit: git revert -m 115. What workflow works best for monorepos and why?
Show answer
Trunk-based development with feature flags. GitFlow in a monorepo creates merge nightmares because one branch contains multiple services. Path-based CI triggers and CODEOWNERS handle the multi-service complexity.🔴 Hard (7)¶
1. Why does git blame often show merge commits on GitFlow's develop branch?
Show answer
Because feature branches are merged with merge commits, git blame attributes lines to the merge commit author rather than the original commit author. Use git blame -w --first-parent or git log --follow for better results.2. What is the correct order for backporting a fix across release branches?
Show answer
Fix on main first, then cherry-pick to the newest release branch, then to older branches. "Fix forward, port backward." Track with labels (needs-backport-X.Y) and automate with bots.3. How does Google practice trunk-based development at scale?
Show answer
Google uses a single monorepo (Piper) with 25,000+ engineers committing to trunk. Tooling includes CitC (virtual workspaces), TAP (continuous testing), and code review before commit. Most teams lack Google-scale tooling.4. What is the riskiest moment when migrating from GitFlow to trunk-based?
Show answer
Merging develop into main and deleting the develop branch. If CI is not solid, main will break immediately. The prerequisite: CI runs in <15 minutes, test coverage >80%, and feature flag infrastructure is ready.5. What organizational signal indicates a workflow/cadence mismatch?
Show answer
When the team spends more time on branch management (cutting releases, back-merging, resolving merge conflicts) than writing features. A 15-person SaaS team on GitFlow recovered 8 engineering hours per week by switching to GitHub Flow.6. What merge strategy compromise balances clean history and bisect granularity?
Show answer
Squash-merge small PRs (<100 lines) for clean history. Use merge commits for large PRs to preserve bisect granularity. Keep PRs small so even squashed commits have manageable diffs.7. Why is a single release manager a risk in GitFlow?