昨天谈到了代码分支模型优化的话题。
今天本来和运维的同学约了聊运维平台和CI/CD这边的接口数据的问题，谈到了上线的若干种场景。
谈到最后，大家发现，发布的版本包的内容，其实问题的症结，就在于生产和仿真的代码内容是会分岔的，同一各版本会先上生产再上仿真。而仿真和生产分岔的时候，如果再产生线上缺陷，就需要发布两个hotfix分别上到这两个环境来解决。
如果在git workflow的基础上再增加一个仿真的分支，可以支持上述场景。问题在于
1）Develop合并谁的内容？
2）如果有只上仿真，不上生产的内容，怎么办？
场景：
某版本R1上完仿真后，仿真/生产代码产生不一致。此时线上（仿真/生产）由于历史遗留缺陷，需要修复，并完成R1的生产上线。
1初始状态下， develop/master/sim三个分支的HEAD相同
image.png
2 在develop分支上开发，并通过release/r1分支准备发布。
image.png
3 在release/r1分支上提交。
image.png
4 release/r1 合并至sim(上仿真)
antony@DESKTOP-4ABGAGB MINGW64 /d/repo/demo (sim)
$ git merge release/r1
Updating c4cf7b3..b29bc3a
Fast-forward
feature1.txt | 2 +-
feature2.txt | 3 +++
2 files changed, 4 insertions(+), 1 deletion(-)
create mode 100644 feature2.txt
上线完成后，从sim分支看代码树
image.png
5 线上(prod/sim)发生历史缺陷，通过hotfix来修复
image.png
image.png
6 hotfix/fix1 merge到master (先上生产)
antony@DESKTOP-4ABGAGB MINGW64 /d/repo/demo (master)
$ git merge hotfix/fix1
Updating c4cf7b3..413ff09
Fast-forward
feature1.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
上完以后master分支的代码树
image.png
7 在sim分支上拉出hotfix/fix1_sim分支准备修复缺陷
antony@DESKTOP-4ABGAGB MINGW64 /d/repo/demo (sim)
$ git checkout -b hotfix/fix1_sim
Switched to a new branch 'hotfix/fix1_sim'
并解决代码冲突。
image.png
image.png
8 将hotfix/fix1_sim 上仿真
antony@DESKTOP-4ABGAGB MINGW64 /d/repo/demo (sim)
$ git merge hotfix/fix1_sim
Updating b29bc3a..9fc954c
Fast-forward
feature1.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
从sim分支上看仿真的代码树
image.png
image.png
9 将hotfix/fix1_sim分支merge到release/r1。更新release/r1分支包含现有master 内容，并修复冲突。准备r1上生产。
image.png
10 r1 完成生产上线。
antony@DESKTOP-4ABGAGB MINGW64 /d/repo/demo (master)
$ git merge release/r1
Updating 413ff09..9fc954c
Fast-forward
feature1.txt | 2 +-
feature2.txt | 3 +++
2 files changed, 4 insertions(+), 1 deletion(-)
create mode 100644 feature2.txt
image.png
完成以后，生产/仿真再次拉齐。
此时，线上的修改hotfix尚未回归到develop。该步骤完成后，所有代码更新完成。
删除hotfix/release下临时分支即可。
网友评论