Hotfix workflow - iToto/developmentCycle GitHub Wiki

Below you’ll find the proper way to go about preparing hotfixes in our work environment. This workflow can be adapted to your personal work habits but please remember you are working on a team and any changes you make to this workflow have to be compatible with the team’s vision for the project.

A new Redmine issue appears with a very high priority reporting a bug in your project. Due to the priority of this issue it’s probably time to drop everything and take a look.

The workflow follows the bug workflow quite closely. There are a few differences.

• You should start by branching off the release tag for the version the user is reporting the bug off of.

• Once the pull request has been accepted, it is necessary to create a new tag as we will be releasing this fix to the customer once it is ready.

• This critical bug may also exist in other existing versions of the software. There may be a business requirement that we update those versions of the software as well. This requires checking out each of those versions and cherry picking your hotfix commits.