Not All Branches Are Equal
As soon as our team grew past three people, our Git history started to fall apart. Merge conflicts. Stale branches. Forgotten experiments. Broken main.
We weren’t bad developers. We were just lacking structure. Everyone had their own branching style. Some committed to main. Others branched for everything—but never cleaned up. We needed a strategy, not just habits.
That’s when I dove into Git workflows. Not just commands, but structures for collaborating in teams. GitFlow, GitHub Flow, trunk-based development—they weren’t buzzwords, they were survival kits.
And through trial and error, I learned what mattered most: purpose. A branch with a clear reason for existing is easier to work with, easier to review, and easier to kill when it’s done.
The Role of Branches in Team Work
A branch is a boundary. It gives you space to work without stepping on others. But that boundary has to be well-defined.
Here’s what made the biggest difference for us:
- Naming conventions (e.g.,
feature/user-profile,bugfix/login-error) - Short-lived branches (merged in days, not weeks)
- Linked to work items (tasks, tickets, goals)
- Deleted after merge
| Practice | Benefit |
|---|---|
| Clear branch names | Easier tracking and communication |
| Short branch lifetimes | Fewer conflicts, faster feedback |
| Delete on merge | Avoid clutter, reduce confusion |
We adopted a lightweight version of GitHub Flow:
- Start from
main - Create a feature branch
- Open a pull request early
- Keep commits clean and focused
- Merge with rebase or squash
It didn’t fix everything. But it gave us a shared rhythm.
Scaling with Trust and Simplicity
At scale, processes collapse under complexity. What worked for 5 engineers didn’t work for 15. So we simplified.
We moved toward trunk-based development for some teams:
- Everyone commits to
mainbehind feature flags - Tiny branches (sometimes a single commit)
- CI gates everything
This was scary at first. But it pushed us toward better testing, clearer ownership, and continuous integration.
| Workflow Style | Best For |
|---|---|
| GitHub Flow | Async teams, moderate size |
| Trunk-based development | High-collab, fast-paced teams |
| GitFlow (legacy) | Complex release/versioning flows |
There’s no one-size-fits-all. But there is one red flag: when branches start living forever, trust starts dying. Long-lived branches usually mean long-unmerged work, lack of confidence, or unclear goals.
Keep branches short. Make them specific. Let them go when they’re done.
Branches Tell Stories Too
We often think of commits as history—but branches are stories too. They show how work evolved, who owned what, and when it was ready.
A well-named, short-lived branch says: “I know what I’m doing, and it’ll be ready soon.” A lingering branch says the opposite.
You don’t need complex rules. You need consistent intent. Use branches to isolate, align, and deliver.
Branch with purpose, and your team will follow.