昨天谈到了代码分支模型优化的话题。
今天本来和运维的同学约了聊运维平台和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下临时分支即可。