A Git Branch and Release Strategy for Product Teams

This post presents a git branch/release strategy intended for use by a team providing long-term development and support for a software product.

The goal is to provide dedicated branches for QA and customer releases while isolating those branches from bleeding-edge development changes.

The Strategy

In this model the repository consists of three types of branches:

• dev for all development.
• qa to create pre-production builds for the test team.
• release to create production builds for release to customers.

All code is merged from dev to qa to release by a team lead or other responsible party, as development and testing progresses.

The dev branch could just as well be main or whatever the repository's default branch is called.

There will typically be several pairs of QA and Release branches, each with their own version string appended. For example qa-1.0, release-1.1, etc.

The dev branch could be versioned as well if there is a need for long-term support of an older version of the software. For example dev-2. Its best if that can be avoided but for mature products there may be a need to support multiple major versions at the same time.

In summary, here is the graph of a set of branches to handle the 1.0 and 1.1 releases of an example project:

In each case there is more than one merge from dev to qa before we identify the final release build.

Code Reviews

An optional approach to lock down dev and only allow changes into it via merge request. That gives the team an opportunity to perform a code review prior to code landing in dev.

Such a policy would be team-dependent. It probably makes more sense on a larger team and/or for an established product where it is important to control code quality and limit risk.

In this model the actual development would take place on feature branches. For example dev-feature-1.

Continuous Integration and Deployment

Automated building and deployment is convenient to have for dev in almost all cases.

QA and Release merges are going to happen much less frequently than pushes to dev but when they do we are going to want a build ASAP. So continuous integration is going to be essential for these branches to ensure builds happen automatically.

Automated deployment may be useful as well depending on your product.

Tagging of Builds

Most teams are going to want their continuous integration script to apply a tag to QA and Release builds. That way there is full traceability into what went into each build as well as the ability to branch directly from the tag in case a hotfix or emergency patch is required.

Development builds are expected to be created frequently and tagging of them is probably not desirable.

Conclusion

This strategy is not a one-size-fits-all solution. But it can work well in practice for products requiring a formal development and release process.

How do you handle branches and releases for your products?