Git Workflows That Don't Slow You Down

You inherited the GitFlow poster. develop is three weeks behind main. Release week is merge-conflict triage with extra meetings. Nobody can tell you when the feature branch from February will land — only that it "needs one more rebase."

That isn't a Git skill problem. It's a workflow mismatch problem. The branching model on the wall was chosen because the diagram looked complete, not because it matched how your team ships.

The Release-Cadence Picker

Before you pick a workflow — or defend the one you're stuck with — answer three questions. Branch taxonomy follows release reality; it doesn't create it.

Deploy frequency. Do you ship to production daily (or multiple times per week), on a sprint boundary, or on a numbered version schedule? Continuous-delivery web teams and mobile apps with App Store review live in different worlds. Vincent Driessen, who wrote the GitFlow model, said in 2020 that teams doing continuous delivery should adopt something simpler — GitHub Flow, for example — instead of shoehorning git-flow into the team. The original GitFlow design assumes discrete releases where master marks production-ready drops and develop holds the next integration target.

Supported versions. Is there exactly one production line, or do customers run 1.2 and 1.3 simultaneously? GitFlow and GitLab's version-branch variant exist for the second case. If you have one deployable web app, you probably don't need a permanent develop branch acting as a second main.

Compliance gate. Do auditors need a formal release branch and tagged version artifacts, or do you need fast rollback and an audit trail in CI? Regulatory release records legitimately justify ceremony. A SaaS team with automated deploys and feature flags usually doesn't.

Run the picker honestly. Most web teams land on: one deployable main, short-lived feature branches, pull request review, green CI before merge. That's GitHub Flow in practice.

GitFlow — When the Diagram Still Earns Its Ink

GitFlow isn't wrong. It's contextual.

It fits explicitly versioned software — desktop clients, mobile apps with parallel store versions, on-prem installs where customers skip upgrades. The model's release and hotfix branches exist because production isn't a single moving target.

It fails the smell test when a continuous-delivery team wallpapering the poster never merges to develop for days, then discovers release week is a three-way merge between main, develop, and a feature branch that outlived its purpose. Teams adopt GitFlow because it felt "professional," then abandon it within months when overhead beat the benefit. The author of the model warned against treating it as dogma.

If you're not shipping versioned artifacts to multiple live versions, you're paying for branch types you don't use.

GitHub Flow — Boring on Purpose

Scott Chacon's GitHub Flow rules fit on a sticky note:

• Slot 1 — Deployable main — Anything on main (formerly master) is deployable.
• Slot 2 — Named feature branches — Branch off main with a descriptive name (oauth-scope-cleanup, not fix-stuff).
• Slot 3 — Push constantly — Commit locally and push to the same named branch on the server regularly. Stale remote branches hide work in progress.
• Slot 4 — Pull request for feedback — Open a PR when you want review or when the branch is ready to merge.
• Slot 5 — Merge after review — Someone else signs off; you merge to main.
• Slot 6 — Deploy immediately — Merged to main means deploy. Don't let merges pile up undeployed.

GitHub's own docs describe this as the lightweight workflow for teams that deploy regularly. There's no develop. No release branch for a SaaS deploy that happens Tuesday and again Thursday.

Branch protection makes this work at team scale: require PR, require green status checks, block direct push to main. That's enforcement without inventing a second integration branch.

Add one more rule most teams forget: delete merged branches. GitHub can do this automatically on merge. Dead branches clutter the remote, confuse newcomers ("is someone still working on this?"), and invite accidental resurrection.

The Integration Tax

Here's the concept that saves you: Integration Tax — the cost of deferring merge grows with branch age.

A feature branch rebased onto main daily might conflict on five lines. The same branch isolated for three weeks conflicts on five files — and someone has to understand both sides. Trunk-based development and GitHub Flow both push toward short-lived branches measured in hours or days, not sprints.

Team rule we actually run: if a branch lives longer than a sprint without merging, it's a planning failure, not a Git problem. Either split the work, merge behind a feature flag, or pair on integration daily. "I'll merge when it's done" is how develop becomes a parking lot.

Concrete path for a five-person web team:

git checkout main && git pull
git checkout -b feature/rate-limit-headers
# work, commit, push daily
git fetch origin && git rebase origin/main   # or merge — pick one team rule
# open PR day two; merge before weekend

Rebase vs merge is a team preference. Flip-flopping per PR is what burns people out.

Watch the review queue, not just branch age. A branch that's only two days old but waiting four days for review is still Integration Tax — the work is integrated in Git, not in the team's attention. Cap review turnaround the same way you cap branch lifetime.

Environment Branches Without Full GitFlow

Sometimes main deploys to staging automatically but production needs a human gate. GitLab Flow adds environment branches — code flows main → staging → production — without resurrecting a permanent develop. That's a staging gate, not a second codebase truth.

Use it when prod deploy isn't automatic from main. Don't use it because the GitFlow PDF had more boxes.

What We Actually Run

On teams I've shipped with — five to eight engineers, web SaaS, deploy multiple times per week — the workflow is deliberately dull:

• main is deployable; protected
• Feature branches live days, not weeks
• PR review + CI green before merge
• Deploy pipeline triggered on merge
• No standing develop branch

When someone joins asking for GitFlow because their last company used it, the conversation is the Release-Cadence Picker, not a holy war. If they came from mobile with parallel store versions, GitFlow might have been correct there. Here, it would be ceremony without payoff.

The awkward middle case: you're on GitFlow because a client contract demanded tagged releases, but your SaaS deploy is continuous. Split the repos or split the rules — don't make every feature ride a release branch because legal once asked for semver PDFs.

Inherited repos with develop as default branch get main as default before culture hardens. Template defaults become team lore fast.

The Part People Skip

Workflow diagrams don't replace CI. GitHub Flow assumes tests catch regressions before merge. Trunk-based patterns assume the same. Branch protection without tests is performance art.

You also don't need merge queues, feature-flag vendors, or monorepo tooling to fix a three-person team that's fighting week-old branches. Fix branch lifetime first. Automate second.

Match the model to how you release. Shorten the branches. Protect main — don't multiply it.