When I started working with Git, most teams were using GitFlow but today, many modern teams (especially cloud and microservices) have moved to something much simpler.
In this article, I’ll explain 3 common approaches:
- GitFlow (old but still used)
- GitHub Flow (simpler)
- Trunk-Based Development (modern best practice)
GitFlow (The Old Standard)
The main idea is that you have multiple long-lived branches:
main → production
develop → integration
feature/* → new work
release/* → preparing release
hotfix/* → urgent fixes
But there are some cons like too many branches, slow delivery, and Frequent merge conflicts!
So, today, GitFlow is often considered heavy and outdated for modern apps.
GitHub Flow (The Simple Version)
GitHub Flow simplified everything, and the main idea is:
- One main branch (main)
- Short-lived feature branches
- Pull Requests (PRs)
- Deploy after merge
This is what many teams use today without even realizing it.
Trunk-Based Development (Modern Best Practice)
This is the approach most modern teams aim for, and the main idea is:
- One main branch (main)
- Very short-lived branches (1–2 days)
- Frequent merges
- main is always deployable
It is very fast delivery but needs automated tests and feature flags for incomplete work.
So the flow has been shifted from:
dev branch -> test branch -> prod branch
to:
main branch -> dev -> test -> prod (via pipeline)
How modern teams use it with DevOps
Then Azure DevOps pipelines:
- Build the app once
- Run all tests
- Deploy to Dev automatically
- Promote the same build to Test
- Promote the same build to Production
Over time, Git workflows have moved from complex and controlled to simple and fast. GitFlow gave teams structure, but introduced too much overhead, while GitHub Flow simplified things and improved delivery speed. And,
Trunk-Based Development takes it further by focusing on continuous integration and fast feedback.
Today, the real shift is not just about branches, it’s about how we deliver software.
Top comments (0)