I see it all the time: teams structuring their branching strategy to mirror their environments. A dev branch for Dev, a staging branch for Staging, a release branch for Production.
It feels logical. It’s also a huge mistake.
Branching by environment creates silos, increases complexity, and slows feedback loops to a crawl. Every additional branch is another place where drift can happen, another bottleneck before value reaches customers. Instead of using branches as proxies for environments, teams should deploy the same code everywhere and control exposure dynamically—with feature flags, progressive rollouts, and real-time observability.
Branches should reflect work in progress, not artificial environments. If you’re still managing code like it’s 2005, it’s time to rethink how you deploy.
How does your team structure branches today? Is it helping or slowing you down?
If you've made it this far, it's worth connecting with our principal consultant and coach, Martin Hinshelwood, for a 30-minute 'ask me anything' call.
We partner with businesses across diverse industries, including finance, insurance, healthcare, pharmaceuticals, technology, engineering, transportation, hospitality, entertainment, legal, government, and military sectors.
NIT A/S
CR2
