Git Workflows: Which One Actually Fits Your Team?

Your Git workflow determines how your team collaborates, how quickly you can ship, and how painful your deployments are. We've seen teams using Gitflow when they ship daily (painful) and teams using trunk-based development with no tests (terrifying). The right workflow matches your team's size, release cadence, and testing maturity.

The Three Workflows at a Glance

Trunk-Based Development: The DORA Favourite

DORA research (State of DevOps reports) consistently shows trunk-based development correlating with high-performing teams. The practice is simple: everyone works off main, branches live for hours not days, and code ships to production as soon as it's merged.

How It Works in Practice

1. Developer creates a branch: git checkout -b add-payment-retry
2. Makes small, focused changes (under 200 lines). Takes 2-4 hours
3. Opens PR, gets quick review (because it's small), merges to main
4. CI runs tests, deploys to production automatically
5. Feature flags control whether new code is visible to users

When Trunk-Based Works

• You have a solid CI/CD pipeline with fast tests (< 10 minutes)
• Your team has strong testing habits (you trust the tests)
• You use feature flags for incomplete work
• You deploy continuously (every merge → production)
• Your team is experienced enough to write small, safe changes

When It Doesn't

• Your tests are slow or unreliable (you can't trust that green means safe)
• You have junior-heavy teams without feature flag discipline
• You need multiple approval gates before deployment (compliance, QA sign-off)
• You ship mobile apps or installed software where "deploy to main" doesn't mean "deploy to users"

GitHub Flow: The Pragmatic Default

GitHub Flow is what most teams should start with. It's Gitflow minus the complexity.

The Entire Workflow

1. Create a branch from main
2. Make changes, commit, push
3. Open a pull request
4. Discuss and review
5. Merge to main
6. Deploy

That's it. No develop branch. No release branches. No hotfix branches. main is always deployable.

Why It Works for Most Teams

It's simple enough that everyone understands it on day one, flexible enough that you can add complexity later (feature flags, release tags) without changing the core workflow, and it maps naturally to GitHub/GitLab's PR-based review flow.

We use GitHub Flow for most of our client projects. The only additions we make: branch naming conventions and a PR template. That's enough structure without adding overhead.

Branch Naming Convention We Use

# Pattern: type/ticket-description
feature/PROJ-123-user-authentication
fix/PROJ-456-payment-timeout
refactor/PROJ-789-extract-email-service
chore/update-dependencies
docs/api-endpoint-reference

Gitflow: When You Actually Need It

Gitflow gets a lot of criticism. Some of it is deserved — it's complex, merge-heavy, and overkill for most SaaS applications. But it solves a real problem: managing parallel development with scheduled releases.

When Gitflow Is the Right Choice

• Mobile apps — You submit to the App Store weekly. You need a release branch to stabilize while features continue on develop
• Enterprise on-prem software — Customers run different versions. You need to support v2.3 and v2.4 simultaneously with different hotfix branches
• Regulated industries — Every release needs formal QA sign-off, compliance review, and audit trail. Release branches provide that structure

When Gitflow Is the Wrong Choice

• You deploy to production more than once a week (GitHub Flow is simpler)
• You have a small team (< 5 devs) — the overhead isn't justified
• You're building a SaaS product with continuous deployment

Decision Framework: Choosing Your Workflow

Feature Flags: The Missing Piece

Feature flags are what make trunk-based development possible and what make GitHub Flow more powerful. They decouple deployment (code reaches production) from release (users see the feature).

// Simple feature flag implementation
const flags = {
  newCheckoutFlow: {
    enabled: process.env.NODE_ENV === 'production'
      ? ['staff@company.com']  // Only internal users in prod
      : true,                   // Everyone in staging
  },
  darkMode: {
    enabled: true,  // Released to all users
  },
};

// Usage
if (isEnabled('newCheckoutFlow', user)) {
  return ;
}
return ;

Feature Flag Tools

Branching Rules That Prevent Chaos

Regardless of which workflow you choose, these rules prevent the most common Git problems:

1. Protect main. No direct pushes. All changes via PR. This is non-negotiable
2. Require CI to pass before merge. Broken main is the single most disruptive event in a development workflow
3. Delete branches after merge. Stale branches accumulate and confuse. Auto-delete on merge is a GitHub setting — turn it on
4. Rebase feature branches on main daily. If your branch lives for 3 days, rebase daily. Small, frequent rebases beat one massive conflict at merge time
5. Squash commits on merge (optional but recommended). "fix typo," "wip," "address review feedback" don't add value to the git history. One clean commit per PR makes git log readable

Frequently Asked Questions