Software Engineering
Git Flow and Branching Strategies
In 2010, Vincent Driessen published Git Flow - the article became one of the most cited in software development. In 2020, the same Driessen added a note to the original post: 'If you practice continuous delivery, Git Flow is probably not the right workflow for you.' A decade of industry experience changed the answer.
- **Google monorepo**: 86TB of code in one repository, ~35,000 commits per day, all into one trunk. Solves merge hell through scale - small frequent commits mean conflicts are tiny.
- **GitHub Flow**: simplified workflow - branch from main, PR, review, merge to main, deploy. GitHub uses it for their own development with hundreds of daily deployments.
- **Stripe API versioning**: strict SemVer, supporting old API versions for years. Allows thousands of clients to update on their own schedule without forced migration.
Git Flow
Git Flow is a branching strategy proposed by Vincent Driessen in 2010. Central branches: main (production code, always stable) and develop (integration branch). Supporting branches: feature (from develop, merged back), release (from develop, for release preparation), hotfix (from main, for production bugs).
Git Flow works well for teams with explicit versioned releases - libraries, mobile apps with app store submissions, enterprise software with quarterly release cycles. In 2020, Driessen himself added a note: 'If your team does continuous delivery, Git Flow is not for you.'
In Git Flow, a critical bug is found in production. From which branch is the hotfix branch created?
Trunk-Based Development
Trunk-Based Development (TBD) means all developers commit directly to main (trunk) or create short-lived branches (maximum 1-2 days). The core requirement: CI must always pass. A commit that breaks the build is an emergency situation requiring immediate fix.
TBD is used by Google (86TB monorepo), Facebook, and Netflix. The key enabler: feature flags hide incomplete features. Branches live for 2 days maximum - long enough to open a PR and get review, short enough to avoid merge hell.
A developer is working on a large feature (2-3 weeks). How is this handled in Trunk-Based Development?
Feature Flags
A feature flag (feature toggle) is a condition in code that enables or disables functionality without deployment. This separates deployment (publishing code to server) from release (enabling a feature for users). Flags enable canary releases, A/B tests, instant rollbacks without code changes.
Types of flags: Release flags (temporary, removed after full rollout), Experiment flags (A/B tests, multivariate), Ops flags (emergency kill switches), Permission flags (beta users, paying customers). Martin Fowler warns: flags are technical debt - they must be removed after use.
How does deployment differ from release when using feature flags?
Release Management
Release management is the process of planning, coordinating, and controlling software releases. Deployment strategies: Blue-Green (two identical environments, instant switch), Canary (gradual traffic shift: 1% -> 5% -> 25% -> 100%), Rolling (replace instances one by one), Feature Flag based (no infrastructure duplication).
Semantic Versioning (SemVer): MAJOR.MINOR.PATCH. MAJOR - breaking changes (API incompatibility), MINOR - new backward-compatible functionality, PATCH - bug fixes. Stripe maintains backward compatibility of API versions for years - clients never need to update unless they want new features.
Stripe maintains 50+ API versions simultaneously. Each version is fully supported. Clients who integrated in 2015 still get reliable behavior. This extreme backward compatibility is what allows millions of integrations without forced migration - the cost is significant engineering discipline.
Trunk-Based Development only works for small teams - large teams require Git Flow with long-lived branches
Google (86TB of code, thousands of developers) and Facebook use Trunk-Based Development. Scale is solved by tooling (monorepo, automated testing), not by branch isolation.
Long-lived branches create merge hell regardless of team size. The real requirement for TBD at scale is investment in CI/CD infrastructure and a culture of small, frequent commits.
During a canary deployment the new version shows p99 latency increase from 200ms to 800ms at 5% traffic. What is the correct action?
Key Ideas
- **Git Flow**: structured workflow with main/develop/feature/release/hotfix branches - suited for versioned releases, excessive overhead for continuous delivery teams.
- **Trunk-Based Development**: commits to main daily, branches live maximum 2 days, unfinished features behind feature flags - the prerequisite for continuous delivery.
- **Feature Flags**: separate deployment (publishing code) from release (enabling for users) - the foundation for canary rollouts, A/B tests, and instant rollbacks.
Related Topics
Branching strategies define how the delivery pipeline is organized:
- CI/CD Pipeline — CI is a mandatory prerequisite for Trunk-Based Development - without automated tests running on every commit, TBD cannot work safely
- Kanban and Lean — Trunk-based development implements Lean's minimum WIP principle at the Git level - small frequent commits minimize work-in-progress
Вопросы для размышления
- Git Flow was created in 2010. What changes in the industry over 15 years made Trunk-Based Development more attractive?
- Feature flags solve the problem of long-lived branches but create technical debt if not removed promptly. How should flag lifecycle management be organized?
- Canary vs Blue-Green: in which situations is each deployment strategy preferable?