Git branching strategy (GitFlow, trunk-based, feature branches) and why maintain separate production and development branches instead of a single branch with tags

• GitFlow uses long-lived develop and main branches plus feature, release, and hotfix branches for scheduled releases
• Trunk-based development keeps everyone on a single main branch with short-lived feature branches merged daily behind feature flags
• GitHub Flow is the middle ground: main is always deployable and every change is a reviewed pull request
• Separate production and development branches give a stable, always-deployable line and a separate integration line, enabling independent hotfixes
• Tags are immutable pointers to commits; you cannot commit onto a tag, so hotfixing with tags alone is clumsy

What is GitFlow?

GitFlow is the most structured model with two permanent branches and three types of temporary branches.

# GitFlow branch structure:
main ─────────────●───────●───────────── (production releases)
                 / \     / \
develop ────●──●────●──●────●──────────── (integration)
           / \      │      / \
feature/  /   \   release /   \
  pay    /     \  /1.2   /     \
        ●───────●       ●───────●
                        hotfix/
                          fix

# GitFlow workflow:
git checkout develop
git checkout -b feature/upi-transfers
# ... develop the feature ...
git checkout develop
git merge --no-ff feature/upi-transfers

# Release preparation:
git checkout -b release/1.2 develop
# ... stabilize, fix bugs ...
git checkout main
git merge --no-ff release/1.2
git tag -a v1.2.0 -m "Release 1.2.0"
git checkout develop
git merge --no-ff release/1.2

# Hotfix for production:
git checkout -b hotfix/fee-rounding main
# ... fix the bug ...
git checkout main
git merge --no-ff hotfix/fee-rounding
git tag -a v1.2.1 -m "Hotfix: fee rounding"
git checkout develop
git merge --no-ff hotfix/fee-rounding

What is trunk-based development?

Trunk-based development is the opposite philosophy, favoured for continuous delivery. Everyone integrates into a single trunk at least daily.

# Trunk-based workflow:
git checkout main
git checkout -b feature/upi-transfers
# Feature branch lives hours, not weeks
# ... develop a small increment ...
git push origin feature/upi-transfers
# Open PR, review, CI passes, merge to main
# Deploy main to production (continuous delivery)

// Incomplete features hidden behind feature flags
public class TransferService {
    private final FeatureFlags flags;

    public TransferResult processTransfer(TransferRequest req) {
        if (flags.isEnabled("upi-transfers") && req.isUPI()) {
            return processUPITransfer(req);
        }
        return processStandardTransfer(req);
    }
}

How do the strategies compare? (comparison table)

| Aspect | GitFlow | Trunk-Based | GitHub Flow |
|---|---|---|---|
| Permanent branches | main + develop | main only | main only |
| Feature branch life | Days to weeks | Hours to 1 day | Hours to days |
| Release mechanism | Release branch | Deploy from trunk | Deploy from main |
| Hotfix mechanism | Hotfix branch from main | Fix on trunk, deploy | Fix on main, deploy |
| Feature flags | Optional | Required | Optional |
| Best for | Scheduled releases | Continuous delivery | Small teams, web |
| CI complexity | High (many branches) | Low (one branch) | Low |

Why keep separate production and development branches?

A production branch is a living line of development: it has a HEAD you can commit onto. When a critical bug hits live, you branch a hotfix from production, fix it, and deploy, all while development holds unreleased work.

# Scenario: critical fee rounding bug in production
# Development branch has an unapproved UPI feature

main (production): v1.2.0 ──── hotfix ──── v1.2.1 (deployed)
                                │
                                └── fix fee rounding only

develop: v1.2.0 ──── UPI feature (not ready to ship)
                      │
                      └── back-merge hotfix from main

# Hotfix without shipping unreleased work:
git checkout main
git checkout -b hotfix/fee-rounding
# Fix the rounding bug
git commit -m "Fix transfer fee rounding for accounts like SAV2001"
git checkout main
git merge --no-ff hotfix/fee-rounding
git tag -a v1.2.1
# Deploy v1.2.1 -- only the fix, not the UPI feature

# Back-merge so develop gets the fix too
git checkout develop
git merge main

Why can tags not replace a production branch?

A tag is an immutable pointer to one commit. You cannot commit onto a tag. If production is several commits behind the branch HEAD, you cannot add a fix on top of the tagged state without dragging in unreleased commits.

# Single branch with tags (problematic):
main: A ── B ── C ── D ── E ── F
           │              │
          v1.2.0        HEAD (has UPI feature)

# To hotfix v1.2.0, you must:
# 1. Create a branch FROM the tag (awkward)
# 2. Fix the bug there
# 3. Merge it back into main
# 4. Now you have an orphaned branch anyway

# With separate branches:
main (production): A ── B ── hotfix (clean, no UPI)
develop:           A ── B ── C ── D ── E ── F (has UPI)

What are common mistakes in branching strategy?

The most common mistake is using GitFlow for a team that deploys continuously, which adds unnecessary ceremony.

# WRONG: GitFlow for a team deploying 10 times a day
# Too many branches, too many merges, slows delivery

# WRONG: Trunk-based without CI or feature flags
# Incomplete features break production

# CORRECT: Match the strategy to the deployment model
# Scheduled releases (banking compliance) -> GitFlow
# Continuous delivery (web services) -> Trunk-based
# Small team, simple releases -> GitHub Flow

What should a senior engineer know?

The branching model must match the deployment model. If you truly deploy trunk continuously, trunk IS production and tags suffice. The separate-branch argument is strongest when there is a real gap between what is released and what is in development, which is common in banking where releases are gated by compliance and change windows.

What are common interview follow-up questions?

• Can you use trunk-based in a bank? Yes, with feature flags and compliance gates in the pipeline.
• What if a hotfix conflicts with develop? Resolve the conflict during the back-merge. The hotfix always goes to production first.
• Why does GitFlow slow continuous delivery? Multiple long-lived branches mean more merge conflicts and longer integration cycles.