Git Notes
Learn trunk-based development where all developers commit to a single branch. Understand feature flags, short-lived branches, and continuous integration practices.
If you have worked at a company practicing GitFlow with long-lived feature branches, you know the pain: branches that live for weeks, massive merge conflicts, integration hell, and the anxiety of merging a 2000-line pull request. Trunk-based development takes the opposite approach and says "what if we just stopped doing all of that?"
Trunk-based development is a source control strategy where all developers integrate small, frequent changes directly into a single main branch (the "trunk"). Feature branches, if used at all, live for hours — not days or weeks. The key insight is that integration pain is proportional to how long you wait to integrate. Integrate constantly, and there is almost no pain.
Companies like Google, Meta, Netflix, and Amazon use trunk-based development to ship code multiple times per day with confidence.
Core Philosophy
The fundamental rules are simple:
- Everyone commits to trunk (main) at least daily
- Branches, if used, live less than one day
- The trunk is always in a releasable state
- Feature flags hide incomplete work from users
- Comprehensive automated tests guard quality
The Daily Workflow
# Start of day: sync with trunk
git checkout main
git pull origin main
# Option A: Direct commit to main (for small changes)
# Make your change...
git add .
git commit -m "fix: correct currency formatting in checkout"
git push origin main
# Option B: Short-lived branch (for slightly larger changes)
git checkout -b fix/button-alignment
git add .
git commit -m "fix: align login button on mobile viewport"
git push -u origin fix/button-alignment
# Open PR → teammate gives quick review → merge within hours
# Total branch lifetime: 2-4 hours
# End of day: ensure you have merged or pushed everything
git checkout main
git pull origin mainFeature Flags: The Enabler
Feature flags are what make trunk-based development possible for larger features. You can merge incomplete code because users never see it:
// Feature flag configuration
const features = {
newCheckout: process.env.FEATURE_NEW_CHECKOUT === 'true',
darkMode: process.env.FEATURE_DARK_MODE === 'true',
aiRecommendations: process.env.FEATURE_AI_RECS === 'true',
};
// Usage in component
function CheckoutPage() {
if (features.newCheckout) {
return <NewCheckoutFlow />; // Still being built
}
return <CurrentCheckoutFlow />; // Stable, shown to users
}The feature flag lifecycle:
# Day 1-5: Developer builds new checkout, merging daily
# Flag is OFF in production, ON in staging for testing
FEATURE_NEW_CHECKOUT=false # production
FEATURE_NEW_CHECKOUT=true # staging/dev
# Day 6: Feature complete, QA passes
# Gradually roll out: 10% then 50% then 100% of users
# Day 10: Stable, clean up the flag
# Remove the if/else, delete the flag, remove old codeRequirements for Success
Trunk-based development requires organizational maturity. It does not work without:
Fast CI Pipeline (Under 10 Minutes): If CI takes 45 minutes, developers cannot get feedback quickly enough. Trunk-based teams invest heavily in test speed — parallel execution, selective testing, and incremental builds.
Comprehensive Automated Tests: Without excellent test coverage, you cannot trust that trunk is always releasable. Unit tests, integration tests, and end-to-end tests must catch regressions immediately.
Feature Flag Infrastructure: You need tooling to manage flags at scale. Tools like LaunchDarkly, Unleash, or custom solutions let you toggle features per environment, per user group, or per percentage.
Team Discipline: Developers must commit to making small, complete, non-breaking changes. A half-finished refactor that breaks trunk blocks everyone.
Monitoring and Alerting: Since code reaches production quickly, you need observability to catch issues fast. Error tracking, performance monitoring, and automated rollbacks are essential.
Trunk-Based vs Feature Branch Workflows
| Aspect | Trunk-Based | Feature Branches | GitFlow |
|---|---|---|---|
| Branch lifetime | Hours | Days | Days to weeks |
| Integration frequency | Multiple daily | Per feature | Per release |
| Merge conflicts | Extremely rare | Occasional | Frequent |
| Release cadence | Continuous | Per PR merge | Scheduled |
| Complexity | Low branching | Moderate | High |
| Required experience | High | Moderate | Any |
| Feature hiding | Feature flags | Branches | Branches |
Handling Larger Features
"But what about features that take two weeks to build?" You have several options:
# Strategy 1: Incremental delivery behind a flag
# Day 1: Merge data model changes (hidden, no UI yet)
# Day 2: Merge API endpoints (hidden, not connected)
# Day 3: Merge UI shell (hidden behind flag)
# Day 4: Merge interactive components
# Day 5: Connect everything, enable in staging
# Day 6: QA and fix
# Day 7: Enable in production
# Strategy 2: Branch by abstraction
# Create new implementation alongside old one
# Both coexist until new one is ready
# Switch the abstraction layer, remove old codeCommon Mistakes
Mistake 1: Adopting trunk-based without automated tests. Without tests, every merge to trunk is a gamble. Build test coverage first.
Mistake 2: Making large commits to trunk. The whole point is small, incremental changes. A 500-line commit defeats the purpose.
Mistake 3: Not cleaning up feature flags. Accumulated flags create technical debt and confusion. Remove flags within days of full rollout.
Mistake 4: Conflating trunk-based with "no code review." Many trunk-based teams use pair programming or rapid asynchronous reviews.
Interview Questions
Q1: What is trunk-based development?
A strategy where all developers integrate small changes into a single main branch frequently — at least daily. Long-lived feature branches are eliminated. Incomplete features are hidden behind feature flags rather than isolated in branches, enabling continuous delivery with minimal merge conflicts.
Q2: How do you deploy incomplete features with trunk-based development?
Feature flags hide unfinished work from users. Code is merged to trunk and deployed to production, but the new functionality is toggled off until complete. This allows gradual rollout and instant rollback without reverting code.
Q3: What are the prerequisites for trunk-based development?
Fast CI pipeline (under 10 minutes), comprehensive automated test suite, feature flag infrastructure, team discipline for small changes, robust monitoring and alerting, and organizational commitment to continuous delivery practices.
Q4: How does trunk-based development reduce merge conflicts?
Everyone integrates daily with tiny changes, so branches never diverge significantly from trunk. When two developers touch the same area, the conflict is caught within hours and involves minimal code, making it trivial to resolve.
Q5: Is trunk-based development suitable for all teams?
No. It requires experienced developers, strong CI/CD infrastructure, feature flag tooling, and organizational commitment. Teams new to Git should start with GitHub Flow and evolve toward trunk-based as their testing and deployment practices mature.
Exam Focus
Revise definitions, diagrams, examples, and short-answer points for Trunk-Based Development - Ship Code Fast and Safely.
Interview Use
Prepare one clear explanation, one practical example, and one common mistake for this Git & GitHub topic.
Search Terms
git-github, git & github, git, github, real, world, workflows, trunk
Related Git & GitHub Topics