Git workflows
An overview of the most common Git workflows — feature branch, Gitflow, trunk-based, and forking — and how to choose the right one for your team.
What is a Git workflow
A Git workflow is an agreed set of conventions for how a team uses branches, commits, and merges to collaborate without stepping on each other. Git itself is unopinionated — it gives you the tools but does not dictate how to use them. A workflow fills that gap by answering practical questions: where does new work live, how does it get reviewed, and how does it reach production.
Why it matters
Without a shared workflow, a team quickly drifts into chaos: half-finished work on the main branch, merge conflicts nobody expected, and releases that are hard to reproduce. A good workflow keeps the main branch releasable, makes review a natural step, and gives everyone the same mental model of where code is in its journey.
The common workflows
This section covers four widely used approaches. Each makes different trade-offs between simplicity and structure:
| Workflow | Best for | Trade-off |
|---|---|---|
| Feature branch | Most teams | Simple; the default starting point. |
| Gitflow | Scheduled releases, versioned products | Structured but heavier with many branch types. |
| Trunk-based | Continuous delivery, strong CI | Very fast; demands discipline and feature flags. |
| Forking | Open source, untrusted contributors | No write access needed; extra fork to manage. |
How to choose
Start with the simplest workflow that fits your situation and add structure only when you feel the pain of not having it.
- A small team shipping a web app continuously is well served by the feature branch or trunk-based approach.
- A product with versioned, scheduled releases benefits from Gitflow's explicit release and hotfix branches.
- An open-source project taking contributions from strangers needs the forking model, because contributors do not have push access to the main repository.
These workflows are not mutually exclusive. Many teams blend ideas — for example, using short-lived feature branches with a trunk-based mindset, or pull requests on top of any of them.
The common thread
Every workflow here builds on the same primitives you have already learned: git branch, git switch, git merge, git rebase, and git push. The workflow is just a convention layered on top of those commands. Master the commands, agree on the conventions, and collaboration gets dramatically smoother.
Practice
Which statements about Git workflows are correct?