Branching strategy
Trunk-based development is the branching strategy for HMCTS repositories. It is what makes continuous delivery possible:
- all changes integrate into the trunk (
mainormaster) - if branches from the trunk are used:
- they originate from the trunk
- they re-integrate to the trunk through a pull request
- they are short-lived and removed after the merge
Work that is not ready for users is merged behind a feature flag rather than held on a long-lived branch.
Git-flow is not recommended, even by its original author. Long-lived develop, release and hotfix branches delay integration and make every merge larger and riskier.
Release branches
Some release processes need a branch that names exactly what was released. Keep a release branch as close to a tag as the process allows:
- cut it from the trunk at release time
- land fixes on the trunk first and cherry-pick them to the release branch, so that nothing exists only on the branch
- merge or delete it once the release is done, rather than letting it become a second line of development
CJS Common Platform (CPP) cuts a release/<version> branch for each release. It can take changes during the release window, and those changes are merged back into main; see the CPP path to live for how a change reaches a release.
A library that supports more than one major version at a time may keep a maintenance branch per major version, for example release/<major>.x. That is a versioning concern rather than a branching one: day-to-day development still happens on the trunk.
Release tooling is not a branching model
A release tool with “flow” in its name does not make a repository git-flow. CPP’s Maven context services use the jgitflow plugin only to bump the version and tag the release on main: its dev/release-<version> branches are never pushed and its dev/release branch is recreated on every run. See the release flow on main.