Git Workflows Compared
Also Known As
Gitflow
trunk-based development
GitHub flow
branching strategy
TL;DR
Gitflow (feature/develop/release/main branches) vs Trunk-Based Development (short-lived branches merged to main daily) — TBD is preferred for CI/CD, Gitflow for release-based software.
Explanation
Gitflow: dedicated branches for features, develop, release, and hotfix. Good for: release-scheduled software with parallel version support, non-continuous deployment. Drawbacks: complex, large long-lived branches, merge hell. Trunk-Based Development: developers push to main (or merge short-lived feature branches < 24 hours). Feature flags hide incomplete work. Good for: SaaS with continuous deployment, microservices. Drawbacks: requires feature flags, CI must be fast and reliable. GitHub Flow is a simplified middle ground — feature branches merged via PR to main.
Diagram
flowchart TD
subgraph Gitflow
GF_MAIN[main] --- GF_DEV[develop]
GF_DEV --- GF_FEAT[feature/x<br/>lives for weeks]
GF_DEV --- GF_REL[release/1.0]
GF_REL -->|merge| GF_MAIN
end
subgraph Trunk-Based
TB_MAIN[main - trunk]
TB_SHORT1[branch - 1 day max]
TB_SHORT2[branch - 1 day max]
TB_SHORT1 -->|merge fast| TB_MAIN
TB_SHORT2 -->|merge fast| TB_MAIN
FF[Feature flags<br/>hide incomplete work] -.-> TB_MAIN
end
style TB_MAIN fill:#238636,color:#fff
style GF_FEAT fill:#d29922,color:#fff
Common Misconception
✗ Gitflow is the industry standard — trunk-based development is standard in high-performing teams per DORA research; Gitflow's long-lived branches conflict with continuous integration principles.
Why It Matters
Gitflow with 2-week feature branches produces massive merge conflicts and integration bugs at the end of each sprint — trunk-based development with daily merges catches integration issues immediately.
Common Mistakes
- Trunk-based development without feature flags — incomplete features visible to users.
- Gitflow with weekly releases treated as daily deployments — mismatch causes confusion.
- Long-lived feature branches regardless of workflow — the longer a branch lives, the worse the merge.
- No branch protection rules — direct pushes to main/develop bypass code review.
Code Examples
✗ Vulnerable
# Gitflow anti-pattern — 3-week feature branch:
git checkout -b feature/payment-redesign
# 3 weeks of work in isolation
# Meanwhile: main has 47 commits
# Merge attempt: 150 conflicts
# Integration testing: finds 12 bugs
# Total time: 3 weeks feature + 1 week merge = 4 weeks
✓ Fixed
# Trunk-based: feature flags + daily merges:
git checkout -b feature/payment-ui # Short-lived
# Day 1: implement basic structure, hide behind flag
git push && git merge main # Merge daily — 0-3 conflicts
# Day 2: add core logic, still behind flag
git merge main
# Day 3: complete, enable flag for beta users
git merge main && delete branch
# Total: 3 days, continuous integration
References
Tags
🤝 Adopt this term
£79/year · your link shown here
Added
16 Mar 2026
Edited
22 Mar 2026
Views
58
🤖 AI Guestbook educational data only
|
|
Last 30 days
Agents 0
No pings yet today
No pings yesterday
Perplexity 11
Amazonbot 8
Google 8
Ahrefs 2
SEMrush 2
Majestic 1
Qwen 1
ChatGPT 1
Also referenced
How they use it
crawler 34
⚡
DEV INTEL
Tools & Severity
🔵 Info
⚙ Fix effort: Medium
⚡ Quick Fix
Use trunk-based development with short-lived feature branches (<2 days) and feature flags — Gitflow's long-lived branches cause integration pain without commensurate benefit
📦 Applies To
git 1.5
any
🔍 Detection Hints
Feature branches open for >1 week; complex merge conflicts; release branches diverging significantly from main
Auto-detectable:
✗ No
git
github
gitlab
⚠ Related Problems
🤖 AI Agent
Confidence: Low
False Positives: High
✗ Manual fix
Fix: Medium
Context: File