better hotfix branch strategy in git flow to avoid commits in master which are missing in develop
During the release of the taxeditor 5.5.0 it turned out, that the
masterbranch has received commits from the
hotfix/* barnch, which are not yet in den develop`:
In this commit the file
eu.etaxonomy.taxeditor.editor/src/main/java/eu/etaxonomy/taxeditor/editor/view/checklist/e4/ChecklistEditorE4.java has been deleted.
This situation finally lead to a conflict when merging the release branch to master.
The git flow scheme clearly recommends merging all changes made to a hotfix branch back to develop. But this can not be done automatically since merge conflicts can are to be expected in this step with high propability.
A good strategy could be to verify just before finalizing the hotfix branch that all changes in the
hotfix/* branch have been incorporated into
develop. The git command
cherry can be used to find commits that have been missed out.
This is illustrated here by a simple example:
- hotfix branch 5.5.1 created
- adding commit to develop:
- adding commit to hotfix/5.5.1 :
305c21a(changes same line)
: git cherry develop hotfix/5.5.1 + 305c21a613ed152685555559f1bdda4eaaed236b
Shows that exactly one commit is missing in
After merging hotfix/5.5.1 into develop and resolving the conflicts git cherry does not report any missing cherries.
*And the case which caused the problem during the release:
in this case we need to focus only to the current hotfix branch and will also specifying the
<limit> argument for the cherry command:
: git cherry 2c28be6 5cb02a2 92f149d1f + e663916103a3e688714d14546aa664cef7f011c6 + 8f3316f456dcafad1b9105ce2323cce5f915fb1a + 5cb02a236f205fd9c7b0b31d3b77fc24c7f8d99d
Without the limit
git cherry would have reported all commit that once have been missed to integrate into develop of which many are no linger relevant for the actual release.
In the above example I needed to use the commit hashes since I was examining a historic situation. At the time of finalizing the hotfix release the command would have been:
git cherry develop hotfix/5.4.3 master
The only problem that needs to be solved is that we need to ignore the first commit in the hotfix branch since this is the commit by which the project version has been bumped by jenkins.
The first commit in a branch created by the release pipeline in jenkins can be found by e.g.:
git log --pretty=format:"%h" --author=jenkins master..hotfix/5.5.1 | tail -n 1
HOW to use the git-hfx-cherry-check.sh script¶
assuming you have checked out the svn repository https://dev.e-taxonomy.eu/svn/trunk/server-scripts at
~/opt/server-scripts you can use the script in the following way:
#6 Updated by Andreas Kohlbecker over 1 year ago
- % Done changed from 0 to 40
Script to check for cherries in the HFX Finish jobs created: https://dev.e-taxonomy.eu/svn/trunk/server-scripts/jenkins-ci/git-hfx-cherry-check.sh
#12 Updated by Andreas Kohlbecker over 1 year ago
- Status changed from Closed to In Progress
- Target version set to Release 5.6
- % Done changed from 100 to 60
it turned out that it can happen that cherries need to be modified when picking them from hotfix to develop. This happens for example when the cherry being picked is causing a conflict. the
git cherrycommand will no longer detect the cherries as identical. to circimvent problems stemming from this we discussed two optional strategies:
Ich denke es ist wichtig, dass wir diesen check der cherries haben, so werden wir auf mögliche Fehler aufmerksam aber wir sollten A) auch zulassen, dass bestimmte commits ignoriert werden können.
B) Alternativ sollten wir uns aber über ein anderes Branchingmodel für die Hotfixes Gedanken machen. Vielleicht so:
- hotfix branches werden nicht nach master gemerged, aber wir behalten den cherry-check bei, dieser führt aber nicht zum einem FAILED des jobs sondern es gibt lediglich einen Report über cherries die nicht nach develop integriert wurden.
- Als Entwickler muss man sich diesen Report ansehen und entscheiden ob diese Commits für develop relevant sind oder nicht.
Nachlesen über die Hotfix-Problematik bei git flow sollten wir auch um zusehen ob andere das selbe Problem haben oder hatten, und zu welchen Lösungen die gekommen sind.
#15 Updated by Andreas Kohlbecker about 1 year ago
- Description updated (diff)
I did a brief research on the topic of hotfix branches:
- git flow has the concept of support branches by which hot fix releases for earlier versions can be maintained (see second link below for details)
- also interesting is that you can allow for multiple hotfix branches at the same time with Git Flow:
git config --add gitflow.multi-hotfix true
for further reading on these topics you may whant to follow these links