What Goes Wrong When You Switch Branching Strategies Mid-Flight

#devjournal #devops #git #softwaredevelopment

I have been part of at least four branching strategy migrations over a 12-year career.

GitFlow to trunk-based. Bitbucket to GitHub. Sprint branches to release branches and back again.

Every time, the decision to switch made sense on paper. Every time, the real problems showed up later, usually during the first production hotfix.

Trunk-based development is the right long-term model for most teams. I am not arguing against it. But I have seen enough transitions go sideways that I wanted to write down what I have noticed, in case it is useful to someone going through the same thing.

The switch usually happens fast

In most places I have worked, the decision to change branching strategies came from leadership during a broader initiative. A platform migration, a new CI/CD tool, a push to modernize.

The intent is always good. But the rollout tends to be uniform. Every repo switches at once, regardless of whether each team is ready for the new workflow.

The thing is, a branching strategy is not really an infrastructure decision. It is a team capability decision. It works when the team's release cadence, test coverage, and deployment setup are aligned with it.

When those things are not in place yet, the new model introduces problems that the old model, for all its flaws, did not have.

The test gap

Trunk-based development assumes main is always releasable. That is a strong assumption.

It only holds if automated tests run in the pipeline as a blocking gate.

In more than one team I have been part of, tests were encouraged but not enforced in CI. Code could land in main without passing automated validation.

In a branch-based model, that is survivable. Bad code sits in a feature or develop branch. You catch it before it reaches production.

In trunk-based, there is no buffer. Main is production. If the pipeline does not block on test failures, you are relying on code review alone to catch runtime bugs and regressions.

I have seen this pattern repeat across organizations. The branching model changes. The test infrastructure does not follow.

The pipeline is the enforcement mechanism. If it does not fail on failing tests, those tests are effectively optional.

The hotfix that could not ship

This is where it gets real.

A critical bug surfaces in production. The fix is reviewed and ready.

But main has other changes in it that are not production-ready. Unfinished features, untested integrations. Deploying the fix means deploying everything.

In theory, trunk-based prevents this because main should always be clean. In practice, that takes time to build: small commits, good CI, feature flags for incomplete work. During the transition period, main is rarely in that state.

I have been in a situation where a straightforward hotfix took over 24 hours to unblock. The pipeline was not set up to deploy from anything other than main. The development team, the engineering manager, and the DevOps team all had to coordinate to add hotfix branch support on the spot.

For teams working on business-critical applications, whether it is healthcare, logistics, or e-commerce, this is especially painful. Hotfixes are not rare events. Access control bugs, data display issues, calculation errors. These come up regularly and need to ship the same day.

A branching strategy that turns a one-line fix into a coordination exercise has a gap that needs addressing.

The pipeline is not always in your hands

Something that rarely comes up in branching strategy blog posts: in many organizations, developers do not control their own deployment pipelines.

The CI/CD setup is owned by a DevOps or platform team. Developers can push code, but they cannot change workflow triggers, deployment rules, or environment settings.

This is a reasonable separation of concerns. But it creates a coordination bottleneck during transitions.

When the team I was on needed hotfix deployments added to the pipeline, it was not something we could do ourselves. It required a request to DevOps, who had to evaluate the change across dozens of repositories. That is a fair concern on their end. But on the development side, there was a fix ready to go and no way to ship it.

Branch naming conventions added another layer. The pipeline required specific patterns like feature/TICKET-ID to trigger builds. Push a branch with a slightly different format, and the pipeline did nothing. No error, no warning. Just silence.

That kind of thing is easy to solve with documentation. But it catches people during the early days of a migration.

When developers cannot see or influence how the pipeline behaves, the branching strategy on paper and the branching strategy in practice are two different things.

Every repo ends up different

One of the more disorienting things about a migration is that different repositories end up at different stages.

Some repos followed a tag-based deployment model. Others deployed from main only. Some had manual dispatch. Others had strict branch naming triggers. The hotfix path that worked in one repo did not exist in another.

During one incident, the tech lead mentioned that different architects had different expectations about the process. Some assumed one workflow, others assumed another. Everyone was working from a different mental model.

Consistency matters more than having the perfect model. Three different "right" approaches across an organization is harder to manage than one imperfect approach that everyone understands.