How to use Git the right way and release with Gitflow Simplified
How I Refined GitFlow with My Teams to Build a Smarter Release Process Without the Clutter
When GitFlow was introduced by nvie.com, it quickly became a popular way to manage software development and releases. The original method emphasized multiple branches, including a develop branch to handle ongoing development alongside the main branch. This worked well for larger teams with more complex workflows, but over the years, I’ve found that this structure can add unnecessary complexity.
After working with various teams across different projects for over 15 years, we evolved GitFlow into something more streamlined, cutting out the clutter and refining the process to make it leaner and more efficient for smaller teams and fast-paced release cycles.
Why Simplify GitFlow?
The biggest reason for simplifying GitFlow is the develop branch. While the original GitFlow model uses the develop branch to manage feature development before merging into the main branch, we realized that for many projects, maintaining this extra layer was slowing things down. It also created confusion, especially when multiple teams or smaller teams were working on various features and hotfixes. So, we dropped the develop branch entirely and streamlined the process.
By shifting to a single internal branch—usually the main or master branch—all work flows through this branch, making the release process simpler and more efficient.
Key Changes in Our Simplified GitFlow
1. No Develop Branch
In this version, all development work starts from the main branch, eliminating the need for a develop branch entirely. Here’s how the flow works:
• Release branches are created from the main branch.
• Feature branches are created from release branches.
• Hotfix branches are created either from the main branch or directly from a specific tag.
This reduces confusion and allows us to focus only on branches that are actively involved in the release or fix process.
2. Tagged Releases, Not Main
One key difference in this approach is that the main branch is never tagged. Instead, all tagging happens at the release branch level. This ensures that all features and hotfixes are contained within specific release versions, which makes it easier to trace and manage versions over time.
After completing a release, the release branch is merged into the main branch, but the tag remains at the release level.
3. Hotfixes Directly from Tags
Hotfixes in this simplified GitFlow come from specific tags that represent production releases. Hotfix branches are created directly from these tags, making it easy to isolate the issue and fix it without disrupting ongoing development. Once the hotfix is completed, it’s merged into the main or relevant release branches, and the hotfix branch is deleted.
For older versions, we use support hotfixes that don’t necessarily merge into newer releases unless there’s a pressing reason to do so. This keeps the workflow focused and avoids unnecessary merges.
4. Multiple Features and Backporting
When multiple features are in progress, they are merged into their corresponding release branches. This keeps the main branch stable and clean. If code needs to be backported to older releases, we decide whether to use merge or rebase based on the complexity of the code and how it differs between versions. In some cases, creating a fresh hotfix is easier than trying to retro-fit a previous fix into newer versions.
Why This Works
By simplifying GitFlow, we’ve kept the essential structure that makes it powerful without adding unnecessary complexity. Teams can focus on development, release management, and bug fixing without worrying about maintaining multiple redundant branches. The main branch stays clean, releases are tagged at the right points, and hotfixes are managed efficiently without disrupting the overall process.
This approach works especially well for smaller teams or projects where rapid development and clear versioning are key priorities. While the original GitFlow model still has its place, this refined version has allowed my teams to move faster and be more agile.
If you’re curious about the original GitFlow model and its branching strategy, you can read the full article by NVIE here.
Thanks for reading! I hope this breakdown of my simplified GitFlow method helps you streamline your release process and avoid the common pitfalls of over-complicated branching strategies.
If you want to dive deeper into Git, software development, and tech insights, make sure to subscribe to my YouTube channel where I regularly upload tutorials like this one. Also, follow me on Twitter for daily updates and tips to keep your dev workflow sharp.
Watch a video of a demo of using this here:
Subscribe to my channel on Youtube: TheGuruCoder
Follow me on X: @snozberryface