GitFlow vs Trunk-Based Development
debt(d7/e7/b7/t7)
Closest to 'only careful code review or runtime testing' (d7). The detection_hints confirm automated=no, and the tools listed (git, github, gitlab) don't flag branching strategy misuse automatically. Misuse only becomes visible through painful merge events, slow release cycles, or team friction — identified via code review of branch patterns or retrospectives, not tooling.
Closest to 'cross-cutting refactor across the codebase' (e7). The quick_fix confirms the remedy is a wholesale strategy change — moving from GitFlow to trunk-based development with feature flags. This requires retraining the team, restructuring CI/CD pipelines, changing branch protection rules, updating documentation, and shifting cultural norms around how work is integrated. It touches every developer's daily workflow and the entire delivery pipeline.
Closest to 'strong gravitational pull' (b7). applies_to is 'any' context, meaning once a team adopts GitFlow the branching model shapes every feature, hotfix, and release workflow. Common mistakes include long-lived diverging branches and merge ceremonies that slow all work streams. The branching model imposes a persistent productivity tax across all team members and CI/CD configuration — every change is shaped by this choice.
Closest to 'serious trap (contradicts how a similar concept works elsewhere)' (t7). The misconception field explicitly states 'GitFlow is the standard that all teams should use' — a widely held belief that leads teams deploying continuously to adopt a model that actively works against them. The trap is that GitFlow is widely promoted as best practice, so a competent developer encountering it assumes it's universally appropriate, when in fact it's only suited to scheduled-release, multi-version products.
Also Known As
TL;DR
Explanation
GitFlow (Vincent Driessen, 2010) defines long-lived branches: main (production), develop (integration), feature/* (short-lived), release/* (stabilisation), hotfix/*. It works well for software with scheduled versioned releases (libraries, apps with manual deployment). Trunk-Based Development (TBD) has developers commit directly to main (or via short-lived branches merged within a day). TBD requires: feature flags to hide incomplete work, comprehensive CI that runs in minutes, and high test coverage. TBD scales better with continuous deployment — GitFlow's long-lived branches accumulate merge conflicts and slow integration feedback. Most modern web applications (including PHP SaaS products) benefit from TBD. GitFlow remains appropriate for open-source libraries and versioned products.
Diagram
flowchart LR
subgraph GitFlow
MAIN[main] --- HOT[hotfix]
MAIN --- REL[release/1.0]
DEV[develop] --- FEAT1[feature/A]
DEV --- FEAT2[feature/B]
REL -->|merge| MAIN
REL -->|merge back| DEV
end
subgraph Trunk-Based
TRUNK[main / trunk]
TRUNK --- SHORT1[short-lived<br/>branch < 1 day]
TRUNK --- SHORT2[short-lived<br/>branch < 1 day]
SHORT1 & SHORT2 -->|merge fast| TRUNK
FF[Feature Flags<br/>for incomplete work] -.-> TRUNK
end
style MAIN fill:#238636,color:#fff
style DEV fill:#1f6feb,color:#fff
style SHORT1 fill:#d29922,color:#fff
style SHORT2 fill:#d29922,color:#fff
Common Misconception
Why It Matters
Common Mistakes
- Long-lived feature branches that diverge massively from main — merges become painful integration events.
- Forgetting to merge hotfixes back into develop — the fix disappears on the next release.
- Using Gitflow for continuous deployment — the release branch ceremony is too slow for multiple deploys per day.
- Not tagging releases — losing the ability to identify exactly what code was deployed at any point.
Code Examples
# Gitflow anti-pattern — hotfix not merged back:
git checkout -b hotfix/critical-bug main
# Fix and deploy to production
git checkout main && git merge hotfix/critical-bug
# Missing: git checkout develop && git merge hotfix/critical-bug
# Bug returns in next release from develop# Gitflow — branch strategy for release-based projects
# Permanent branches:
# main — production-ready at all times
# develop — integration branch for features
# Temporary branches:
# feature/TICKET-123-add-mfa — from develop, merge to develop
# release/2.5.0 — from develop, merge to main + develop
# hotfix/CVE-2024-critical-patch — from main, merge to main + develop
# Workflow:
$ git checkout -b feature/TICKET-456-password-reset develop
# ... work ...
$ git checkout develop && git merge --no-ff feature/TICKET-456-password-reset
# For most web apps, prefer trunk-based development:
# Single main branch + short-lived feature branches + feature flags
# Simpler, faster CI/CD, less merge conflict pain
# Use Gitflow only if you need to support multiple release versions