Git Workflow Strategies: Trunk-Based vs GitFlow in 2025

The Git Workflow War

The debate between trunk-based development and GitFlow has been going on for years. In 2025, the industry has largely settled on trunk-based development for high-performing teams, but GitFlow still has valid use cases.

GitFlow: The Feature Branch Model

GitFlow uses long-lived branches for features, releases, and hotfixes:

main ──────────────────────────────────────────────────────────
  \                    /          \              /
   develop ──────────────────────────────────────
     \         /   \         /
      feature/A     feature/B

# Start a feature
git checkout develop
git checkout -b feature/user-dashboard

# Work on feature (days/weeks)
git commit -m "Add dashboard layout"
git commit -m "Add chart components"
git commit -m "Add API integration"

# Merge back to develop
git checkout develop
git merge --no-ff feature/user-dashboard
git branch -d feature/user-dashboard

# Create a release
git checkout develop
git checkout -b release/2.1.0
# Bug fixes only on release branch
git commit -m "Fix dashboard loading state"

# Merge release to main and develop
git checkout main
git merge --no-ff release/2.1.0
git tag v2.1.0
git checkout develop
git merge --no-ff release/2.1.0

GitFlow advantages:

• Clear separation between in-progress and released code
• Multiple versions can be maintained simultaneously
• Release candidates can be stabilized in isolation
• Well-suited for software with versioned releases (mobile apps, libraries, on-premise)

GitFlow problems:

• Merge conflicts accumulate on long-lived branches
• Integration is delayed (find bugs late)
• Release branches add process overhead
• Branch management becomes complex with many features
• Slows down deployment frequency

Trunk-Based Development: The Fast Lane

Trunk-based development has everyone committing to a single branch (main/trunk) with short-lived feature branches (max 1-2 days):

main ──●──●──●──●──●──●──●──●──●──●──●──●──────
       |     |  |        |  |        |
       └─●──●┘  └──●──●──┘  └──●────┘
       (hours)    (1 day)    (hours)

# Start work (branch lives < 24 hours)
git checkout main
git pull
git checkout -b yash/add-search-filter

# Small, focused commits
git commit -m "Add search input component"
git commit -m "Add filter logic to product grid"

# Push and create PR
git push -u origin yash/add-search-filter
# Create PR, get review, merge same day

# On merge, CI/CD deploys to production automatically

Trunk-based advantages:

• Continuous integration (find bugs immediately)
• Smaller PRs (easier to review, faster to merge)
• No merge hell (conflicts are small and frequent)
• Deploy multiple times per day
• Forces modular, decoupled code

Trunk-based requirements:

• Strong CI/CD pipeline (automated tests must be fast)
• Feature flags (to deploy unfinished code safely)
• Code review culture (small PRs reviewed quickly)
• Good test coverage (confidence to merge to main)

Feature Flags Enable Trunk-Based

The key enabler for trunk-based development is feature flags. You can merge incomplete features to main without exposing them to users:

// Merge to main with flag off
if (featureFlags.isEnabled('new-checkout', user)) {
  return <NewCheckoutFlow />;
} else {
  return <LegacyCheckoutFlow />;
}

Deployment flow:

1. Merge code to main (flag off)
2. Deploy to production
3. Enable flag for internal team
4. Enable flag for 10% of users
5. Enable flag for 100% of users
6. Remove flag and dead code

Comparison

The Hybrid Approach

Many teams use a practical hybrid:

# Trunk-based with short-lived branches
main (protected, requires PR + CI)
  ├── feature/xyz (lives < 2 days)
  ├── fix/abc (lives < 1 day)
  └── release/v2.1 (only for mobile/versioned releases)

Rules:

1. Feature branches must be merged within 2 days
2. PRs must be under 400 lines changed
3. CI must pass before merge
4. Main is always deployable
5. Feature flags for incomplete features

Branch Protection Setup

# Gitea branch protection (API)
curl -X PUT "http://localhost:3000/api/v1/repos/yash/techsaas-website/branch_protections/main" \
  -u 'yash:Eagle@2904' \
  -H 'Content-Type: application/json' \
  -d '{
    "enable_push": false,
    "enable_push_whitelist": true,
    "push_whitelist_usernames": ["yash"],
    "require_signed_commits": false,
    "enable_status_check": true,
    "status_check_contexts": ["ci/build", "ci/test"],
    "block_on_rejected_reviews": true,
    "dismiss_stale_approvals": true
  }'

Our Recommendation

For web applications and SaaS products, use trunk-based development. The faster feedback loops, smaller merge conflicts, and continuous deployment capabilities are worth the investment in CI/CD and feature flags.

For mobile apps, libraries, and software with versioned releases that need long-term support, GitFlow or a modified version with release branches makes more sense.

At TechSaaS, we use trunk-based development with branch protection on all our Gitea repositories. Every push triggers CI (build + security scan), PRs require passing CI before merge, and we deploy from main multiple times per day. Feature flags through Directus CMS let us merge code without exposing unfinished features.