Sauter git workflow : CASE Engine Working with hotfix candidates - sauter-hq/git-guidelines GitHub Wiki

Description:
Often the contingency arises in the event that an official version is released and a very important bug is found only later.
On the one hand, this bug should be quickly solved. But on the other hand, the management decided later whether or not to launch a patch/hotfix.
The project manager has (mainly) two capabilities:

  • Solve this bug inside a feature on the basis of the current development (branch)
  • Create a hotfix-branch and solve it inside this branch

Both of these have disadvantages:
In the first case, you must later "cherry-pick" the changes from this feature branch and merge them into a newly created hotfix-branch on the basis of the master.
This is very bold, because you must pick all commits (all of those but not more). In addition, violent merge conflicts may occur during this (mostly time-critical) process, because these branches were created on the basis of different source branches.
In the second case, if this bug should not be included in any hotfix in contrary to expectation, but others may well be included, you have created a hotfix-branch with code, where only a part of it should really be included in the hotfix.

Therefore, we (the CASE Engine team) have decided to solve all those important bugs inside "hotfix-candidate"-branches which are always created on the basis of the latest master-branch.
After such a bug is solved (all work is done), this code (the branch) is merged into the current development branch to ensure, that it is at least contained in the code for the next version. During this process, any arising merge conflict can be solved by the developer.
If a hotfix containing a solution for this bug is planned later, the project-manager simply can merge the corresponding code into a newly created hotfix-branch.
In that case (during this very often time-critical process), no or only little merge conflicts should occur, because both branches were created on the same basis.

The following steps must be performed by the developer who works on a very important incident (a possible „hotfix-candidate“):

  1. Checkout the master branch by double clicking on it.

  2. Pull this master-branch!
    This must be done to ensure, that you are working on the most current version of master before you create a new branch on the basis of this master-branch.

  3. Manually create a new branch for the hotfix-candidate:

    CE Hotfix Candidates Manually Create Branch To do that:

  • with checked out master click on the «Branch»-button in the toolbar
  • give the branch a name (best practice is corresponding to the IN-number)
  • the name of the branch must begin with the prefix «hotfix-candidates/», because it should be created in the «hotfix-candidates»-folder.
  • all other options should be left on their default values, as it is shown in the picture.
  • press the «Create Branch»-button.

  1. The new branch should be shown under the «hotfix-candidates»-folder:

    CE Hotfix Candidates Hotfix Candidates Folder

  2. If everything is fine, push the changes to the server.

  3. Do your work on this "hotfix-candidate", commit your changes and push all to the server.

  4. After your work is finished, you must manually merge these changes into the develop-branch.
    To do that:

  • Checkout the develop-branch by double clicking on it
  • Pull it if necessary, to be working on the most current version of develop.
  • Thereafter, select the hotfix-candidates-branch (i.e. the branch IN12345 in this example) by simply clicking on it (no double click).
  • From the context menu of this branch choose the option: «merge hotfix-candidates/IN12345 into current branch»:
    CE Hotfix Candidates Hotfix Manually Merge Branch
    Confirm the next message.
    During this merge you can get some merge conflicts. These must be solved before you can push your changes.

  1. If all is finished, push your changes to the server.

  2. Now all changes from this hotfix-candidate are also included in the current development-branch for the next version.

  3. All of these hotfix-candidates are located on the server for an eventually later use in a real hotfix.
    They are still not included in the master branch. This is right, as it is not known yet, if a real hotfix will be released and/or if all of these candidates should be a part of an hotfix.

If a real new hotfix is planned later, the project manager has to do the following additional work:

  1. The project manager must create a new hotfix-branch with the name of the hotfix (for example „3.2-patch-2014-07“).
    This can be done using git flow („start new hotfix“) as it is described in the git-guidelines.

  2. The project manager must manually merge all those candidates into the hotfix, which should really be included in it.
    This can be done in the same kind as described above, i.e. by checking out the hotfix branch, selecting one candidate by one and choosing the option «merge hotfix-candidates/XYZ into current branch» for each of them.

  3. After the official release of this hotfix, it should be merged into the master-branch.
    This can simply be done using gitflow („finish hotfix“), as it is described in the git-guidelines.
    Do not forget to tag this patch/hotfix in the master-branch!
    During this process, all of the changes for the included hotfix-candidates are also merged into the develop-branch again. But this has no bad influence, because git „knows“ that these merges are still performed earlier (during step 7. above).

  4. Thereafter, all of the included hotfix-candidates could be renamed to get a better overview.
    This seems to be a good practice, if there exist many such candidates.
    To do that:

  • Rename the hotfix-candidate-branch in your local repository. For example from "IN12345" to "IN12345-in-patch-2014-07"
  • Delete the original hotfix-candidate-branch (i.e. "IN12345") on the remote server (be careful to get the right one!)
  • Push the renamed branch to the server.