The Big Picture: Why This, Why Now
I didn't invent this workflow, I distilled it. After years of wrestling with overly complex branching models, I kept what worked and threw out what was brittle. This guide is the straightforward, battle-tested approach I wish I'd had when I was starting out. It grew from the frustration of untangling messy branches, chaotic releases, and disorganized repositories.
Below is the complete visual guide to this branching model. Refer to it anytime you need to see how the pieces fit together. Or, you know, print it out and hang it on your wall. Whatever works.
The Core Philosophy
Why this workflow? Because I've seen enough projects descend into branch-induced madness to know that, most of the time, simplicity and discipline are the only remedies. This isn't about adding rules for the sake of it; it's about agreeing on a simple playbook that prevents chaos.
It boils down to this: we need one playbook for the whole team, from the fresh-faced junior to the grizzled veteran. No more freestyle branching where every feature is a new adventure in chaos. We need to protect main at all costs, because it's our sacred source of truth-what's running in production. Unfinished, untested, or unreviewed code doesn't even get to look at it.
Following this process gives you a Git history you can actually read. It becomes a clean, linear story of shipped features and fixed bugs. A rollback should be a routine procedure, not an archaeological dig that ruins your weekend. And most importantly, it leads to drama-free releases. Deployments should be boring, not a reason to pull the fire alarm every Friday afternoon.
Let's be clear: the core ideas here aren't new. This is a flavor of Trunk-Based Development, heavily inspired by battle-tested models like GitHub Flow and adapted with the stability of GitFlow's release process.
"But GitHub Flow is too simple! It's for continuous deployment and won't work for our complex release schedule!"
I used to think that, too. And you're partly right. Pure GitHub Flow is aggressive and biased. That's why this model adapts the support and hotfix process from GitFlow, giving you the stability needed for scheduled releases.
This hybrid approach is designed for modern platforms like GitLab and GitHub. Their Protected Branches and Pull/Merge Requests (PRs/MRs) are the gatekeepers that make this system work. They are what ensure no unapproved, untested, or unfinished code ever pollutes your sacred main branch.
The Journey Ahead
I'm going to walk you through the four scenarios that make up 99% of a developer's life:
- ✨ Feature Development: The daily grind. Your bread and butter, made smooth and predictable.
- ✅ Tasks and Merge Trains: For monster features that can't be handled by yourself in one go. I'll show you how to divide and conquer without losing your mind.
- 🚀 Tagging and Releasing: How to formally bless your work, cut a release, and let the world enjoy your genius (or report new bugs).
- 💉 Support and Hotfixes: When things go wrong in production. A calm, controlled process for patching old releases without setting your hair on fire.
Pay attention to how Semantic Versioning and Conventional Commits are woven into every step. They aren't just "nice-to-haves"; they're the engine that lets automation make this whole system sing. I'll also sprinkle in some command-line tricks that will make you look like a wizard and keep your history pristine.
Don't just read it. Do it.
I'm not writing commands all over this documentation for my health. Use the command line first. Once you understand the mechanics, feel free to use a GUI for reading, but I strongly advise against using it for complex operations like merging or rebasing.
It's the only way to understand what Git is actually doing under the hood.
Keep the Git Command Cheatsheet bookmarked. It summarizes everything so you don't have to re-read my ramblings just to find a command.