Welcome dear reader, today you will learn about the most popular branching strategies in Git. In other words, we’ll cover the agreements a team makes about how code travels from an idea to production. Git itself does not enforce a workflow; it gives you lightweight branches, and you decide how to use them. Picking a strategy that fits your team is one of the highest-leverage decisions in day-to-day development.
Table of contents
- What is a Branching Strategy and Why Do You Need One?
- How Does Git Flow Work?
- How Does GitHub Flow Work?
- What is Trunk-Based Development?
- Conclusion
What is a Branching Strategy and Why Do You Need One?
A branching strategy answers three questions: where does new work happen, how does finished work get merged, and what does the state of production look like? Without an agreement, teams end up with long-lived branches that drift apart, painful merges, and release-day surprises.
Basically, the three strategies below cover the vast majority of real-world teams — from corporate platforms shipping quarterly releases to small teams deploying many times a day.
How Does Git Flow Work?
Henceforth, the most structured strategy is the Git Flow. It keeps two long-lived branches: main holds production-ready code, and develop holds the latest integrated work. Every task lives in a feature branch cut from develop:
# Start a new feature from develop git checkout develop git checkout -b feat/user-notifications # Once finished, merge it back into develop git checkout develop git merge --no-ff feat/user-notifications
Besides, releases get their own branch for stabilizing and hotfixes, and finished releases are merged into main with a version tag. Git Flow suits products with scheduled releases, but the ceremony can slow smaller teams down — a feature flag or release branch naming convention like ours, feat/{category}/{topic}, keeps things organized regardless.
How Does GitHub Flow Work?
GitHub Flow is the streamlined alternative: there is only one long-lived branch, usually main, and every change goes through a short-lived branch and a pull request:
# Create a topic branch and push it git checkout -b fix/broken-footer git push -u origin fix/broken-footer # Open a pull request, get it reviewed, merge
Indeed, the review happens before anything lands in main, and merging main triggers deployment. This workflow powers most open-source projects — and it is exactly the review process we use for the articles on this platform, with humans merging every pull request.
What is Trunk-Based Development?
Trunk-based development goes one step further: developers commit very small changes directly to main (the trunk) — or merge branches that live for hours, not weeks. To avoid breaking production with incomplete code, it is common to hide unfinished featuresbehind feature flags. Teams practicing it can deploy continuously, at the cost of needing strong automated tests.
Conclusion
That’s already it for our tour of Git branching strategies. Git Flow brings structure for scheduled releases, GitHub Flow adds just enough review for most teams, and trunk-based development enables continuous deployment. Pick the lightest strategy your release cadence allows. Leave a comment below with the workflow your team uses, and why!
At re:Software S.L., we create innovative solutions for businesses that aim to digitize their processes and routines, and version control systems like Git are key to build and release open source software!