Project

General

Profile

bug #8105

Updated by Andreas Kohlbecker about 5 years ago

During the release of the taxeditor 5.5.0 it turned out, that the `master`branch has received commits from the `hotfix/*` barnch, which are not yet in den develop`: 


 ![](picture794-1.png)  

 *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: `c6191df` 
 * adding commit to hotfix/5.5.1 : `305c21a` (changes same line) 

 ![](picture794-2.png) 

 ~~~ 
 : git cherry develop hotfix/5.5.1 
 + 305c21a613ed152685555559f1bdda4eaaed236b 
 ~~~ 

 Shows that exactly one commit is missing in `develop` 

 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:* 

 ![](picture205-1.png) 

 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. 

Back