We see many agile and Scrum teams struggle with complex branching strategies, and the result is nearly always a bottleneck in delivery. With a strong technical background, we have helped teams simplify their workflows, improve automation and adopt practices that give fast feedback and higher-quality engineering.
The recurring pattern is a reliance on complex branching, not because it is the best choice, but because it masks deeper problems in automation, feedback loops and quality engineering.
Those branching strategies often contribute to hidden technical debt that slows a team down over time. Instead of enabling agility they create friction, and even small changes become risky and slow. Teams unaware of the growing debt end up with slow releases, frequent production issues and brittle systems. Here is how technical debt silently threatens agility.
Trunk-based development (TBD) is the preferred approach of high-performing teams. There are cases where GitFlow or another strategy makes sense, particularly in open-source projects where maintainers need tight control over contributions. But most teams default to feature branching or pull-request-heavy workflows as a workaround for missing technical excellence, rather than fixing the root cause.
The pitfalls of complex branching
Branching is seen as a safeguard, but long-lived branches introduce real problems:
- Merge conflicts waste time. The longer a branch lives, the more painful the merge.
- Delayed feedback leads to defects. Isolated development stops the team catching issues early.
- Code becomes harder to change. Working in silos makes integration and refactoring difficult.
- Release coordination becomes a nightmare. Managing several branches creates overhead and delay.
- Cycle times increase. Work sits in branches instead of being continuously integrated and tested.
Trunk-based development: a more efficient approach
Trunk-based development removes the bottleneck of long-lived branches by integrating frequently into the main branch. Instead of managing several feature branches, developers work in small increments, committing directly to trunk or using short-lived branches that merge within hours.
The key benefits
- Faster feedback. Immediate integration surfaces issues early.
- Fewer merge conflicts. Small, frequent commits keep complexity down.
- Higher stability. Continuous integration keeps the code always deployable.
- Simpler release management. No complex merges before shipping.
- Clean, modular design. It forces the team to keep code loosely coupled and testable.
A real example: removing branching to unlock agility
We have helped many teams move away from strategies like GitFlow, which usually mask immaturity in continuous integration and DevOps practice.
One team believed they had been "doing Scrum" for three years. When we asked which environment they deployed to at the end of the Sprint, they had no answer. Development was followed by a testing Sprint, and the team unpicked code whenever they wanted to release.
The root cause was a complicated branching strategy that let them keep many things in flight. Even small changes were hard to merge, feedback was delayed, and releasing was frightening. A release was a big event with heavy coordination and preparation.
Meanwhile a neighbouring team in the same department, on the same tech stack with a slightly different product, had a 15-minute deployment cycle to a production-ready environment. We had coached that team for two years, helping three teams work on a single trunk-based product in the same codebase. For them a release was an activity, not an event, something they did several times a day with confidence.
Feature branching is the other strategy we encourage teams to leave behind, especially when it is paired with a pull-request workflow. Short-lived feature branches look harmless, but they bring slow feedback, excessive gatekeeping and delayed integration. Most teams we have helped move to trunk-based development end up not using feature branches at all, because they no longer need them.
Removing the long-lived branches was only part of the solution. It also took:
- Fixing separation of concerns and SOLID violations. The system needed proper modularisation and APIs that delivered real business value, not just CRUD operations.
- Investing in the CI/CD pipeline. Their pipeline was constantly red or ignored. We made it a first-class citizen.
- Improving feedback loops. The team needed fast, local feedback before pushing. We made green builds a priority and encouraged a shift towards continuous improvement.
- Pair and mob programming. Instead of code review after the fact, the team worked together in real time. That spreads knowledge, removes the need for long-lived branches, and builds a collaborative engineering culture.
These practices are the foundation of technical excellence, and technical excellence is what makes a high-performing engineering team. Strong automation, modular code and clean architecture do more than enable trunk-based development. They remove the friction that made feature branching feel necessary.
GitFlow: why it is not ideal for most teams
GitFlow adds unnecessary complexity for teams practising continuous integration and continuous delivery.
Where GitFlow works best:
- Open-source projects with many external contributors.
- Strict gatekeeping requirements, where contributions must be managed.
- Limited automation, where an organisation still relies on manual approval.
Why trunk-based development excels:
- Enables business agility. Frequent integration lets the team adapt quickly and deploy value faster.
- Reduces deployment risk. Smaller, more frequent releases reduce the chance of a large-scale failure.
- Improves engineering culture. It favours collaboration, clean architecture and automation over manual gatekeeping.
- Accelerates time to market. No delays from merge conflicts and lengthy approvals.
- Scales DevOps. Fast feedback and continuous integration let the team grow without losing quality.
How to move to trunk-based development
Moving from GitFlow or feature branching to trunk is not just about merging faster. It needs investment in five technical practices.
1. Feature toggles
- Let the team commit incomplete work without exposing it to users.
- Reduce the need for long-lived branches by enabling controlled rollouts.
2. Continuous integration and automated testing
- Every commit should trigger automated tests that confirm the system is stable.
- Without strong test automation, trunk-based development is risky.
3. Pair and mob programming
- Real-time feedback instead of delayed code review.
- No developer works in isolation on a long-lived branch.
4. Deploying in small batches
- Small, incremental deployments reduce risk and improve stability.
- Large releases add complexity and raise the chance of failure.
5. An architecture that deploys in isolation
- Clean architecture and well-defined service boundaries enable independent deployment.
- Avoid poorly implemented microservices that do not line up with real business problems.
The three ways of DevOps
The shift to trunk-based development lines up with the three ways of DevOps:
- Flow. Reduce wait time and move small changes quickly through the pipeline.
- Feedback. Shorten feedback loops so issues are caught and fixed early.
- Learning. Experiment, measure, and keep evolving your practices.
Follow these and the team delivers faster, with less risk and better product quality.
The future is trunk-based
GitFlow had its place before modern DevOps. Today, trunk-based development is how high-performing teams that value speed, automation and rapid feedback work.
- It eliminates delays. No long-lived branches, merge conflicts or release bottlenecks.
- It enables continuous delivery. Seamless integration, automated testing and rapid iteration.
- It drives business agility. Teams adapt quickly to market change.
- It powers high-performing teams. The standard for organisations focused on innovation and speed.
There is no one-size-fits-all, though. If your team is not ready for trunk-based development, start by investing in automation, testing and feature flags to ease the transition.
As Jez Humble said: "If it hurts, do it more often."
The best teams do not manage branches. They continuously deliver value.
Next steps
If your team struggles with slow feedback, painful merges or a complicated release process, trunk-based development is the way forward. To understand the hidden costs you are already paying, read how technical debt slows teams down. If you want help improving your engineering practices and culture, talk to us about coaching.