Most teams think they have a "Git workflow." What they actually have is a set of habits that accumulated over time, often made by people who left the company years ago, based on assumptions that no longer hold.
Ask three developers on the same team to explain "how we use Git" and you'll get three different answers. Not because anyone is wrong — because the team never actually made the decisions explicitly. They made them by accident.
This article is about surfacing those decisions. Not telling you what's right — telling you what you're implicitly choosing, so you can choose deliberately.
The four decisions
Every team, whether they know it or not, has made a choice about four things:
- Branching strategy — How does code move from idea to production?
- Tracking methodology — How do you decide what to work on and measure progress?
- Release cadence — How often does code reach users?
- Automation level — How much of the workflow is human-driven vs event-driven?
Each decision constrains the next. Each one, if not made explicitly, gets made implicitly — and implicit decisions tend to contradict each other.
Decision 1: Branching strategy
Your options, roughly:
- Trunk-based development — everyone commits to (or merges small changes into) main, multiple times a day
- GitHub Flow — feature branches, short-lived, merged via PR to main
- GitLab Flow — feature branches + environment branches (staging, production)
- Git Flow — long-lived develop + main branches, release branches, hotfix branches
- Custom hybrid — some combination of the above
Most tutorials frame this as "which is best?" The honest answer is: it depends on the next three decisions. Git Flow with continuous deployment is a contradiction. Trunk-based with a monthly release train is a waste.
The right question isn't "which strategy should we use?" — it's "which strategy supports the other three decisions?"
Decision 2: Tracking methodology
This one most teams think they've decided, but haven't.
- Scrum — sprints, story points, planning/retro ceremonies
- Kanban — continuous flow, WIP limits, no sprints
- Waterfall or phase-gated — requirements → design → build → test → deploy
- SAFe or other scaled framework — multiple teams coordinating via ARTs or similar
The question that reveals your actual methodology: what triggers work to start?
- If it's "this sprint's plan" → you're doing Scrum (or pretending to)
- If it's "capacity is available and this is prioritized" → you're doing Kanban (or should be)
- If it's "this phase is complete and signed off" → you're doing Waterfall (admit it)
- If it's "a manager said so" → you're in a methodology vacuum, which is its own problem
The implications for Git are direct. Scrum with 2-week sprints wants branches that close before sprint end. Kanban doesn't care about time — it cares about WIP limits. Waterfall expects phase-gated tags. These are incompatible constraints on how your branches live.
Decision 3: Release cadence
This is the one most teams lie to themselves about.
- Continuous deployment — every merge to main goes to production (with canary, feature flags, etc.)
- Continuous delivery — every merge to main is production-ready, but deployment is a manual trigger
- Release train — scheduled releases (weekly, biweekly, monthly)
- Ad-hoc releases — "when it's ready," which usually means "when someone has time"
The diagnostic question: how long from a developer's merge to users seeing the change?
- Hours → you're on continuous deployment
- A day or two → continuous delivery
- Consistent schedule → release train
- "Varies" → ad-hoc (and your lead time is probably terrible)
Release cadence is the cruellest decision to get wrong, because it interacts with everything:
- Long cadence + trunk-based = huge batch risk
- Short cadence + Git Flow = unnecessary overhead
- Ad-hoc + Scrum = sprint goals that never ship at sprint end
Decision 4: Automation level
Unlike the others, this is a spectrum, not a discrete choice. But at a high level:
- Fully automated — PR opens → CI runs → auto-merge on approval → auto-deploy to staging → auto-promote to prod (with gates)
- Event-driven — Git events trigger most transitions; humans handle exceptions
- Semi-manual — CI runs, humans approve and merge, humans decide when to deploy
- Fully manual — every step requires a human action
The test of your automation level: what happens at 2 AM when a hotfix needs to ship?
If the answer is "we page someone who manually runs the deploy script," your automation level is semi-manual at best. If the answer is "the hotfix workflow handles it; we review the result in the morning," you're much closer to the automated end.
The decision table
Here's what it looks like when a team makes all four decisions consistently:
| Team Type | Branching | Tracking | Release | Automation |
|---|---|---|---|---|
| SaaS startup | Trunk-based | Kanban | Continuous | High |
| Regulated fintech | GitLab Flow | Scrum | Biweekly | Medium |
| Enterprise product | Git Flow | SAFe | Quarterly | Medium-high |
| Open source project | GitHub Flow | Issue-driven | Ad-hoc | High |
| Regulated hardware | Custom | Waterfall-hybrid | Milestone-based | Low-medium |
Notice that each row is internally consistent. The branching strategy supports the cadence. The tracking methodology matches the release frequency. The automation level is appropriate for the regulatory context.
Natural combinations that work
Trunk-based + Kanban + continuous deployment + high automation. This is the SaaS ideal. Works when the team is small-to-medium, the product tolerates continuous change, and there's sufficient test coverage. Fastest feedback loop, but requires discipline.
GitHub Flow + Scrum + continuous delivery + medium-high automation. The most common mid-size-team setup. Feature branches align with sprint items. Continuous delivery means each sprint can ship if the business decides. Good for product teams at B2B SaaS companies.
Git Flow + SAFe + release train + medium automation. Enterprise reality. Multiple teams coordinating, scheduled releases, version-branching for support of multiple production versions. Unfashionable, but genuinely correct for some contexts.
Combinations that create friction
Git Flow + continuous deployment. Your long-lived develop branch creates unnecessary batching. Why have develop if you deploy on every merge? You're paying the cost of Git Flow without getting its benefits.
Trunk-based + quarterly release train. You're merging to main continuously, but users don't see the changes for 3 months. Either deploy more often, or use longer-lived branches. The current setup batches risk without batching value.
Scrum + ad-hoc releases. You commit to sprint goals, but the output doesn't reach users at sprint end. The team's measurement of success (sprint completion) is divorced from actual delivery. Over time, developers stop believing sprints matter.
Kanban + Git Flow. Kanban is about continuous flow; Git Flow creates flow-blocking integration points. Every release branch is a ceremony Kanban is designed to eliminate.
The test: can you write down your answer?
Here's a diagnostic exercise that takes 10 minutes and is worth more than most consulting engagements:
Write down the four decisions for your team, as one sentence each.
- "We use GitHub Flow."
- "We use Scrum with 2-week sprints."
- "We release every Thursday at 2 PM."
- "PR opens trigger CI automatically; merges trigger deploy-to-staging automatically; promotion to production requires manual approval."
If you can write these four sentences confidently, and every senior person on the team would write approximately the same four sentences, you have a workflow.
If different people would write different sentences, or if you find yourself writing "it depends," or "we kind of do X but sometimes Y" — you don't have a workflow. You have accumulated habits pretending to be a workflow.
And that's fine to discover. The discovery is the start of fixing it.
Your workflow will evolve
One more thing: these four decisions aren't permanent. Teams grow, products mature, regulations change.
A startup that started with trunk-based + continuous deployment may, at 50 developers, realize that coordination requires feature branches. That's not a failure — that's scale demanding a new set of decisions.
A mature enterprise product might, after adopting feature flags and improving test coverage, discover it can move from quarterly release trains to biweekly. That's not a rebellion — that's capability unlocking a new set of decisions.
The mistake isn't in the specific decisions. The mistake is making them implicitly, letting them drift, and then wondering why delivery is slow and everyone's frustrated.
Make them explicit. Revisit them quarterly. Change them when the context changes.
That's how you go from "we have a Git workflow" to actually having one.
This post is adapted from Git in Depth: From Solo Developer to Engineering Teams, a 658-page book with a full chapter on the complete map connecting board columns, Git states, and deployment environments — plus decision frameworks for choosing the right combination for your team.
Related: Your Kanban board is lying to you (and Git knows it) · Little's Law: the math that explains why your team delivers slowly.
See all my articles on Git and engineering practice: dev.to/matutetandil.
Top comments (3)
A brilliant breakdown of how "invisible" Git habits eventually become technical debt if not explicitly defined. The focus on making these four core decisions early is a masterclass in establishing the kind of predictable, scalable developer workflow that prevents CI/CD friction down the line.
Thank you — really appreciate it. The "invisible until it's debt" framing is exactly the trap: teams usually only see the cost when onboarding a new engineer or when a release goes sideways, and the workflow can't explain itself. By then, the friction is already structural.
That's actually one of the threads I pull through Part II of Git for the Working Developer — the four decisions plus everything that grows around them (branch governance, review culture, release management). Happy to share a sample chapter if it sounds useful.
Absolutely! I'd love to take a look at that sample chapter. The way you've connected branch governance and review culture to these core decisions is spot on, and it's rare to find content that handles the structural complexity so well. I'm especially interested in seeing how you address the 'why' behind the decisions rather than just the 'how.' Thanks for sharing!