Preface
When using the git flow process, project-type deployment projects often encounter a problem, that is, some problems discovered when using historical versions of on-site projects need to be fixed, but upgrades may There will be a great risk or the customer is unwilling to upgrade. In this case, hotfix repair based on the historical version is required.
The defect repair method based on the historical release version is different from the patch repair method of the latest release version. Because the branches of historical versions are merged into the master, the directory structure and files may be very different, resulting in conflicts that cannot be merged normally.
Merge based on latest released version
Generally speaking, everyone knows that if a problem that needs to be fixed is found on the latest tag of the master, the branch will be directly pulled based on the tag that needs to be fixed and repaired. After the modification is completed, the code will be merged into the master to issue a patch version, and merged into In the current develop or release branch.
git checkout 6.0
git checkout -b hotfix/6.0.1After the repair is completed in the hotfix_version branch, merge it into the master release tag.
git checkout master
git merge hotfix/6.0.1
git tag 6.0.1Merge changes into develop or release (mainly depends on which stage you are currently in), the example is develop stage
git checkout develop
git merge hotfix/6.0.1
git branch -d hotfix/6.0.1After the develop branch is subsequently merged into master, the log images of develop and master will reference hotfix, and the display will be messy, as shown in the figure below
* b66ca1b (tag: 2.0) Merge branch 'develop' ==> master 合并 develop
|\
| |
| * df20397 develop update 2
| * d0ed525 develop update 1
| * 778bd03 Merge branch 'hotfix-1.0.1' into develop ==> 引用到 hotfix-1.0.1 的修改
| |\
| * | 26a23fd git develop add a file t1.txt
* | | cb413a9 Merge branch 'hotfix-1.0.1' ==> master 合并 hotfix-1.0.1, 引用到了 hotfix-1.0.1 修改
|\ \ \
| | |/
| |/|
| * | 959dfc5 (hotfix-1.0.1) hotfix 1.0.1 update 2
| * | ecc876d hotfix 1.0.1 update1
|/ /
* | 679c836 this is a hotfix for 1.0.1
|/
* a27b457 (tag: current, tag: 1.0) add three line
* 72e54f1 add two line
* 5418748 add one lineYou can use merge -squash to compress the merge of hotfix to develop. The log image display will be clearer, as shown in the following figure:
* 51ae281 (HEAD -> master) Merge branch 'develop'
|\
| * 5532d53 (develop) Squashed commit of the following: ==> develop 通过 squash 合并 hotfix-3.0.1, 没有引用 hotfix-3.0.1 修改
| * e9942da this is a develop update 2
| * efc9829 this is a develop update 1
* | ec8d038 Merge branch 'hotfix-3.0.1' ==> master 合并 hotfix-3.0.1
|\ \
| * | ccae1bf (hotfix-3.0.1) this is a hotfix-3.0.1 update 1
| * | d00da78 this is a hotfix 4.0.1
|/ /
|/
*At this point, the entire process is completed.
Merge based on historical releases
However, if the tag to be repaired is a historical version, the support long-term branch needs to be introduced, which has a similar function to master and is used to release the tag version.
git checkout 6.0
git checkout -b support/6.x
git checkout -b hotfix/6.0.1After the repair is completed in the hotfix_version branch, merge it into the support branch and publish the tag.
git checkout support/6.x
git merge hotfix/6.0.1
git branch -d hotfix/6.0.1
git tag 6.0.1If the gitflow command line tool is used, it can be simplified to:
git flow support start 6.x 6.0
git flow hotfix start 6.0.1 support/6.x
# 问题修复后
git flow hotfix finish 6.0.1 However, hotfix modifications cannot be directly merged into the master, which will cause a particularly large conflict. Therefore, they must be merged into the latest development or release first. It is not recommended to merge directly through the merge command without parameters, which will cause a long process. Log reference path.
It is recommended to use cherry-pick or merge -squash for merging.
git checkout develop
# 单个合并
git cherry-pick commitid
# 或使用 squash 合并
git merge -squash hotfix/6.0.1DONE