Fixing and Hot Fixing

At some point in time, we will inevitably have to make a fix to a version of our app that is going to be or is already released in production. If the issue is discovered by QA prior to the release branch being promoted to production, then this is a fix. If the issue is discovered after the release is already in the wild, promoted to production, this then becomes a hot-fix.

The steps to deploy a fix are entirely the same for both scenarios. It is important to note that the process will be completely different IF (!) the files that need fixing have been updated with code that should not be included in the current release. Both processes are outlined below.

(Easy) When the offending file hasn't changed since the release branch was created.

• Create a new branch from main
• Work on the required fixes and get them merged back into main. When your MR finally gets merged in, you'll have the option to Cherry-pick it into another branch:

• You should now either:
  • If the release you're trying to fix hasn't been published: Cherry pick these changes into the appropriate unreleased-release branch (e.g. release/8-20-0).
  • If the release you're trying to fix is already published:
    • Checkout into the release branch that requires fixing (e.g. release/8-20-0) and create a new branch from it with an incremented 'patch' version number (e.g. release/8-20-1).
    • Cherry pick your fixes into this new release branch (e.g. release/8-20-1).

(Not-so-easy) When the offending file HAS changed since the release branch was created

If a file that needs fixing has been changed since the release branch creation date, then we need to ensure ONLY the bug fix is merged into the release branch, without any other changes that someone else might've made to the same file. Here's what this looks like in a real-life scenario:

01/Jan/2000: A release/1-0-0 branch is published to production\ 02/Jan/2000: John Smith changes the colour of our Countdown component to #222222\ 03/Jan/2000: Jane Doe fixes a critical bug where the Countdown component was not correctly memoised and resulted in poor performance. \ 04/Jan/2000: A new branch is created for release/1-0-1 as we're hoping to get Jane's bug fix to production as soon as possible. The change from 02/Jan/2000 should NOT make it into this release.

This will only be possible if Jane Doe creates a new branch from the commit that was used to create release/1-0-0. If she creates a cherry pick from main she would also be pushing the colour changes made by John Smith on 02/Jan/2000.

To do this, follow the steps below:

• Checkout to the the commit (or tag) in main which was used to create the release branch affected by this bug

• Create a new branch from said commit and perform the required bug fixes.

• Create an MR targeting the appropriate release branch. Yes, you're targeting a release branch for now, NOT main.

  • If the release you're trying to fix hasn't been published: Cherry pick your changes into the appropriate unreleased-release branch (e.g. release/8-20-0).

  • If the release you're trying to fix is already published:

    • Checkout into the release branch that requires fixing (e.g. release/8-20-0) and create a new branch from it with an incremented 'patch' version number (e.g. release/8-20-1).

    • Make your MR target this new release branch (e.g. release/8-20-1)

      DO NOT forget to untick this checkbox when submitting your MR:

• Once your bug-fix has landed on the appropriate release branch, it's time to bring it back to main. This involves rebasing main into your bug-fix branch, and then submitting another MR targeting main (you're probably familiar with this process already).

If you're a visual learner, the diagram below should do a better job at explaining: | Unpublished releases | Published releases | |----------------------|--------------------| | | |

Determining the fork-point of a branch

In the past we've used 'tags' to keep track of where each branch was forked from. However, these can be incorrect, can be changed, deleted and don't have a strict naming structure. Moving forward, we can use git to tell us this with the following command.

git merge-base --fork-point SOURCE_BRANCH FORKED_BRANCH

Eg: git merge-base --fork-point origin/main origin/release/8-29-1

In this example, the command will print the commit hash at which origin/release/8-29-1 was forked from origin/main.