Our Branching Strategy: Lessons Learned and Best Practices

Whilst we were in the middle of our project, one of the decisions we had to make was how to structure our Git branching strategy. We knew that an effective workflow would help us collaborate smoothly, maintain stability, and keep deployments predictable. But like many teams, we had to experiment and iterate before settling on a process that worked for us.

Here’s what we learned along the way.

Initial Challenges

We didn’t have a clear branching strategy in place. This led to a few key issues:

Merge Conflicts Galore – Without a structured workflow, developers often worked on overlapping changes, leading to painful conflicts.
Unclear Release Process – We needed a way to differentiate stable production code from in-progress features.
Hotfix Chaos – When critical bugs were found, we had to scramble to figure out the best way to patch them without disrupting ongoing work.

To address these challenges, we settled on a branching strategy inspired by GitFlow, but with some modifications to fit our workflow.

Our Git Branching Strategy

1. main Branch: Production-Ready Code Always stable and deployable. Only updated through pull requests (PRs) from develop or hotfix branches. Protected branch: No direct commits allowed.
2. develop Branch: Staging and Integration The main working branch where feature branches are merged. Developers branch off develop when starting new work. Regularly deployed to staging for testing.
3. Feature Branches (feature/*) Each feature or improvement gets its own branch off develop. Named based on feature scope (e.g., feature/login-ui). Merged back into develop via PRs after code review.
4. Release Branches (release/*) Created when preparing a new version for production. Allows final testing, bug fixes, and versioning before merging into main. Once stable, merged into both main and develop to keep everything in sync.
5. Hotfix Branches (hotfix/*) Used for critical bug fixes in production. Branched directly from main and merged back into main and develop. Ensures urgent fixes are applied without disrupting ongoing development.

What We Expect to Improve

🔹
Since this is a new process for our team, we anticipate several key benefits:

Streamlined Release Process – Instead of maintaining long-lived release/* branches, we expect that reducing their duration or, in some cases, merging directly from develop to main when appropriate will help us move faster while maintaining stability.

Better Automation – With our CI/CD pipeline in place, we hope that enforcing automated testing and quality checks at the PR level will prevent regressions and improve overall code quality.
As we put this branching strategy into practice, we’ll be monitoring its effectiveness and making further adjustments as needed.

Final Thoughts

A solid branching strategy isn’t just about following best practices—it’s about adapting to what works best for your team. While GitFlow provided a great foundation, tweaking it to fit our needs made all the difference.

If you’re struggling with your branching workflow, don’t be afraid to experiment. Find a balance between structure and flexibility, and your team will thank you for it.

🚀 How does your team handle branching? Have you made modifications to GitFlow or use a different approach entirely? Let’s discuss in the comments!