Trunk-based development, feature flags, and branch strategies — a practical comparison to help you stop arguing about Git and start shipping faster.
The right Git workflow reduces integration conflicts, accelerates delivery, and keeps deploys boring — which is exactly what a healthy engineering team wants.
Why Your Git Workflow Is a Product Decision
Most engineering teams treat their Git workflow as a purely technical decision. It is not. Your branching strategy determines how often you integrate code, how long features sit in review, and how painful deployments are. Those factors directly shape your release cadence and your team's ability to respond to production incidents.
The goal is not to find the theoretically correct workflow — it is to find the workflow that reduces integration pain and keeps the main branch deployable at all times.
Gitflow: Powerful but Often Overkill
Gitflow was designed for products with scheduled, version-based releases — think desktop applications or embedded firmware. If you are deploying a web app continuously, its overhead works against you.
- Long-lived feature branches accumulate merge debt that compounds into painful integration weekends
- Release branches create a second place where bugs are fixed, diverging history and generating cherry-pick confusion
- Hotfix branches require merging into both
mainanddevelop, a process that is frequently done incorrectly under pressure
Trunk-Based Development: The High-Performance Default
Trunk-based development (TBD) has one rule: everyone commits to main at least once a day. Short-lived feature branches (under 24 hours) are acceptable; anything longer is a code smell that should trigger a conversation about task sizing, not a workflow exception.
- Create a branch from
main— name itfeature/short-description - Work in small, complete increments — each commit leaves the branch deployable
- Open a PR within 24 hours and merge the same day if possible
- Use feature flags to ship code that is not yet user-visible
- Delete the branch immediately after merge — no exceptions
If it hurts, do it more often. The pain of frequent integration is infinitely preferable to the agony of infrequent integration.
— Jez Humble & Dave Farley, Continuous Delivery
Feature Flags: The Missing Piece
Trunk-based development only works if you can separate deployment from release. Feature flags (also called feature toggles) let you merge incomplete features into main behind a conditional check, ship them to production, and enable them only when the feature is ready. The code ships continuously; the feature ships deliberately.
Code Review Practices That Complement Your Workflow
The workflow is only as effective as the review culture around it. Reviews on long-lived branches accumulate context that reviewers no longer have; reviews on small, focused PRs are fast, effective, and actually happen. A good rule of thumb: if a PR takes more than 30 minutes to review, it is too large.
Set a team norm: PRs under 400 lines changed get reviewed within 2 hours during business hours. PRs over 400 lines require the author to break them up before requesting review — no exceptions, no "I'll just merge this one big one." This single norm does more for velocity than any branching strategy change.
Choosing Based on Team Size
Under 5 engineers, almost any workflow functions — the friction is low enough that process does not matter much. At 5–20 engineers, trunk-based development with feature flags is typically the highest-leverage choice. Beyond 20, you may need a more structured approach to coordinate releases across teams, but the principle of keeping the main branch deployable at all times remains non-negotiable regardless of scale.
