My very large team is following trunk based development with many short lived features branches, trunk, and a release branch for when we create release artifacts. This is a team that keeps the release branch around while a release is ‘live’ in case we need to go back and patch the previous release. In other words, our customers want us to patch the older release and not always get the new features in our trunk. Trunk based development says to delete release branches too once they are hardened.

Would it be a violation to keep these release branches around from a purely philosophical perspective when it comes to trunk based development ? Or in the nature of a business where we need to go back and patch that branch is it normal then to have a variation on trunk based development to keep the release branches around for a long time ? Or better yet how do we recover that point in time if we don’t explicitly merge the release branch back to the trunk and simply push to the release branch and trunk for patches ?

  • 2
    Emergency hotfixes on releases is a real thing. Jul 3, 2021 at 0:40
  • If a release has a critical bug and you aren't ready to do a new release, how else would you fix the bug?
    – DaveG
    Jul 3, 2021 at 2:00
  • @DaveG this would be months later Jul 3, 2021 at 3:05

1 Answer 1


In trunk-based development, there are two prevalent release strategies: release from trunk and branch for release (which is what you are doing). Both have their uses, depending on other factors in the context where the team is working.

In the case of using a branch for release, there's no problem with keeping the release branch around for as long as there is a need to support the release:

Release branches are deleted some time after release activity from them ceases. Not immediately, but when it is clear release is no longer in production.

If you have to support a particular release in production for months or years, then the associated release branch can live for that length of time. However, for long-lived release branches, the practice of committing the fix to the trunk and cherry-picking it into the release branch may not be viable if the defect no longer lives on the trunk - the implementation could have been significantly refactored or the defective implementation (or feature as a whole) removed.

However, if you end up with many release branches in production, you may want to look at using tags instead of branches. This can help keep some of your tools for viewing and managing your repository neater and easier to use, but you can create a new branch from a tag to apply a patch at any time when a defect is discovered. However, if the implementation no longer lives in the trunk, you may end up with a release branch for a patch living for a long time. I would suggest, though, that if you are frequently patching, you understand why and try to reduce the number of versions that you support at a given time.

  • You should definitely be tagging every release. If you do then it doesn't matter if you delete release branches, the commits won't be lost and you can recover the branches later at any time. Jul 3, 2021 at 14:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.