Overview #
Our branching strategy is designed to keep development organized, predictable, and safe while allowing teams to move quickly. By separating active development from production-ready code, we reduce the risk of defects reaching live environments and ensure that changes can be reviewed, tested, and traced before deployment. This approach supports collaboration across teams while maintaining a stable and reliable product.
Core Branches #
The main branch represents the production environment and always contains stable, deployable code. Direct commits to this branch are restricted to prevent unreviewed changes from reaching production. Updates to main occur only after code has passed review and validation through our release process.
The develop branch serves as the primary integration branch for ongoing work. It contains features and fixes that have been completed but are not yet released to production. This branch allows multiple streams of development to come together in a controlled environment where testing and validation can occur before a release is finalized.
Feature Development #
New functionality is developed in dedicated feature branches created from the develop branch. Isolating features in this way allows developers to work independently without disrupting others or affecting shared code. Feature branches remain active only for the duration of the work and are merged back into develop once the feature has been reviewed, tested, and approved. After merging, the branch is removed to keep the repository clean and easy to navigate.
Bug Fixes #
Non-critical defects are addressed through bugfix branches that also originate from the develop branch. This ensures that fixes are tested alongside other upcoming changes before being released. Once a bug fix has been validated and approved, it is merged back into develop so it can be included in the next scheduled release.
Hotfixes #
When a critical issue is discovered in production, a hotfix branch is created directly from the main branch. This allows urgent fixes to be applied without waiting for the full development cycle. After the fix has been tested and deployed, the changes are merged back into both main and develop to ensure consistency between production and ongoing development.
Pull Requests and Reviews #
All changes are introduced through pull requests, which provide a structured way to review and discuss code before it is merged. Pull requests document the purpose of the change, link it to related work, and trigger automated tests. Code reviews focus on correctness, security, performance, and long-term maintainability, helping maintain a high standard of quality across the codebase.
Merging and History #
To keep the repository history readable and meaningful, feature and bugfix branches are typically squash-merged. This approach groups related commits into a single, coherent change, making it easier to understand why a modification was made. Rebasing may be used to resolve conflicts and keep branches aligned with the latest changes before merging.
Releases and Versioning #
Releases are created by merging the develop branch into main once testing and validation are complete. Each production release is tagged using semantic versioning, which clearly communicates the scope and impact of changes. This makes it easy for users and internal teams to track updates and understand compatibility.
Maintenance #
To maintain clarity and reduce overhead, merged branches are regularly removed and inactive branches are reviewed and cleaned up. This ensures the repository remains organized and easy to work with over time.
This branching strategy allows us to deliver features efficiently while protecting production stability, providing a balance between speed, quality, and reliability that scales as our systems and teams grow.