Hotfix Branches
  • 23 Jan 2023
  • 3 Minutes to read
  • Dark
  • PDF

Hotfix Branches

  • Dark
  • PDF

Article Summary

Hotfix branches allow developers to quickly fix critical issues in a production environment by working with the exact code deployed in production. Once the code is fixed, it can be quickly tested and deployed, and later merged into the main code. Like feature branches, hotfix branches prevent interfering with ongoing development.

There are a few options for integrating hotfix branches into your CI/CD pipeline. In this article, we'll discuss:

Using Hotfix Branches in Git

A hotfix branch should be created from the commit that's currently deployed to production. Generally, this commit will be tagged with a version number to make it easier to find.

For example, if you needed to fix SAML-based logins, you might do the following:

  1. Identify the production tag or commit (e.g. 4.2.1 or f839162)
  2. Create a new branch from that point (hotfix/4.2.1-saml-login-fix)
  3. Write code and commit the changes to this branch
  4. Push the branch to your Git server
  5. Collaborate with other developers and testers to verify the fix
  6. Deploy the hotfix code to production
  7. Tag the commit with the new version number (e.g. 4.2.2)
  8. Optionally, merge into a main branch
  9. Delete the hotfix branch

In some cases, merging the code back into a main branch will be unnecessary. The issue may have already been addressed in the in-development release, or a new feature would have made the fix impractical to merge.

Using Hotfix Branches in a CI/CD Pipeline

To test hotfix changes, production-ready builds should be created in hotfix branches. These hotfix branch builds should be deployed to production. Unlike builds created from the main or development branch, they are guaranteed to have minimal changes from production code.

Creating a Hotfix Branch Pipeline in BuildMaster

BuildMaster includes a Hotfix Branch Pipeline template to help you get started. You can customize any aspect of the pipeline you need, or even create the same pipeline from scratch.

The Hotfix Branch Pipeline template includes the four default stages:


The stages work mostly like they would in other pipelines: the Build stage will run a Build script, and the Integration, Testing, and Production stages run a Deploy script.

💡BEST PRACTICE: Hotfix Branch Pipelines

Builds created from hotfix branches should follow the same build and deployment process as other builds, often using the same scripts. For some teams, a dedicated hotfix pipeline is not required: you can simply create builds from your regular pipeline and override/force settings that would otherwise prevent deployment from a non-main branch.

Unlike most pipelines, in this template the Deployment Eligibility option is set to not enforce pipeline the stage order for deployments. This setting means that you can deploy to any stage without having successfully deployed to a previous stage, which is often desirable for hotfixes. For example, a build that uses this pipeline could skip Integration, and go from Build to Testing to Production.


To help mitigate an accidental deployment, deploying into Production requires an approval.


After a build is deployed to Production, you must manually set it as deployed.

Monitoring Git for New Hotfix Branches and Commits

You can configure a Git Repository Monitor to automatically create new builds when a new hotfix branch is created or a commit is detected on a hotfix branch.

To do this, navigate to Settings > Resource Monitors in your application and click Add Monitor. After selecting Git Repository Monitor from the list, you can specify a branch filter that uses a wildcard expression such as hotfix/*`:


The expression hotfix/* will create a build when a new branch that starts with hotfix/` is detected, or if there are any new commits to such a branch.

If you need to monitor multiple branch patterns, just create additional repository monitors.

Was this article helpful?