git并行开发工作流说明
文章发霉了，晒一晒
日期：2020年7月8日前
整体原则
假设有A/B两个分支在开发。
- 如果B需要独立上线，即使A在开发中，为了保证B不被A污染，禁止dev和beta分支merge into B。
- 因此，B解决与dev的冲突时，仅需要在dev上解决，而解决beta分支的冲突时，由于权限问题，需要在本地拉取一个临时的beta_b分支用于冲突解决，而后合到beta。
- 后续B在解决冲突的过程中，可以直接合到beta，如果仍有冲突（因为其他分支也在合beta），仍需要用beta_b过度一下。
- 如果AB可以协商同步上线，那么整个开发过程AB可以选择独立分支，也可以选择合并在一起开发，内部冲突协商解决方式。
- 可以是独立开发，提dev时相互merge一次，以其中一个分支为准进行后续流程。
- 可以是一开始就在一起开发。
关于通过提测后分支处理
- 独立/插队上线的分支通过测试后，发布到sbeta21后，需要合回dev和beta，让上游感知最新代码。
分支上下游概念
属于相对概念，参考时间线或代码最新出现点，对于先发生的，可以称为上游。如dev总是先于beta拥有最新代码，则dev是beta上游。
关于线上bug修复
- 线上bug的修复（sbeta或master），必须基于发生bug的分支拉出修复分支进行修复。
- 线上bug修复后，需要及时分发到上下游。需要方可以根据情况选择merge和cherry-pick。
关于配置项
- 对业务影响敏感的配置项，在merge后必须审查合并结果对应的变更。
流程案例梳理
开发起始点
需求分析与技术方案出完后，根据需求紧急度选择从某分支拉取代码进行开发。
- 不紧急，按计划进行的，且无并行忧虑的，从beta或dev分支拉取。
- 紧急，需要基于稳定版本，保证开发代码的联调和测试不受其他未测试代码污染，需要基于sbeta或master拉取分支。
假设现有两个feature分支A/B
如果B此时需要和A并行开发，优先协商是否同时提测。
- case1 如果可以同时联调提测，可以在merge into dev环节，先把A/B merge into A或B，假设这里选择merge into A，那么后续流程都是由A去和dev、beta、sbeta等交互。
- case2 如果无法保证同时，A、B实际上进入到并行流程。
此场景基于A为第一个进入开发周期的分支，而B是与A并行开发的，可能要保证优先上线的分支。
为描述简单，以下流程简化掉push过程。
基于此场景，A可以从beta拉取分支。B必须从sbeta21或者master上拉取分支。
联调
A视角流程（先行开发分支视角）
假设A时间上优先进行开发（可计划，或根据实际，谁优先合到dev，不一定是优先上线的）
-
A先行合到dev进行联调，不需要关注B的情况。 -
A分支开发完，合到dev供联调，联调中禁止merge dev into A。 -
dev修复A相关的bug时，在A上修复完merge A into dev。如果有冲突，及时解决dev上的冲突。 -
重复3直至联调完毕。
B视角流程（优先上线分支视角）
-
由于流程上A将优先进入提测，但B先于A上线，则禁止merge A into B，以防被污染。
B如果不优先上线，而且需要感知A所有已提交的代码，那么需要merge A into B。
-
merge B into dev，期间禁止 merge dev into B，以防被污染。
B如果不优先上线，而且需要感知dev中已提交的代码，那么需要merge A into B。注意dev中含有的未经beta测试的代码的影响。
-
同A的修复流程，修复自己bug，如有冲突及时解决dev上的冲突。
如果A中修复了bug，B可以根据需要是否cherry-pick（这里根据对A的依赖程度谨慎考虑是否需要merge）。
-
重复3，直至联调完毕。
提测
A视角（先行开发分支视角）
-
联调完毕提测时，拉取beta 最新代码：git checkout beta & git pull -
建立预备分支，解决冲突。
Tips：冲突简化流程的条件：
git checkout beta_A from beta- 在本地
merge A into beta_A，解决冲突后，pull requests: merge beta_A into beta。
-
beta修复A相关的bug时，在A上修复完，merge into Beta_A，然后pull requests: merge Beta_A into beta。
Tips：冲突简化流程的条件：
-
重复3，直至通过提测。 -
通过提测后，merge beta into A，merge beta into dev，使dev上获得最新可靠的代码。
B视角（优先上线分支视角）
-
如果B需要先于A提测上线，则不需要mergeA。
假设B不是优先上线的分支，如果A已经提测，根据对A的依赖，考虑是否需要先merge A into B，防止后续更多的冲突。
如果A已经通过了提测，推荐此时merge A into B，除非B对污染程度要求特别高，不希望任何代码的干扰。
-
更新本地最新的beta代码。 -
建立预备分支解决冲突:
checkout Beta_B from betamerge B into Beta_Bpull requests: merge Beta_B into Beta
Tips：冲突简化流程的条件：
- 如果确定没有冲突，可以直接
merge B into beta。仅在有冲突时采用3中给出的流程。
-
beta修复B相关的bug时，在B上修复完merge into beta。如果有冲突参考2和3. -
通过B相关提测后，
-
更新dev：merge beta into dev。由于B需要防污染，这里不要merge beta into B。但仍需要使dev保持最新。 -
更新仿真：merge sbeta21 into B，解决冲突后，merge B into sbeta21.
如果确定无冲突，可以直接 merge B into sbeta21。
-
更新master: merge sbeta21 into master.
流程需要确保这里总是没有冲突。
sbeta21到master的流向只有在发生bug时可能会产生短期的不一致，需要修复bug的分支往上游分发。
仿真数据同步与代码合并流程注意事项
问题描述：
提往sbeta分支的代码如果有flyway脚本修改了db数据或者结构， 在代码合并到sbeta后，因为可能会有同步生产db到仿真的行为，导致仿真的代码和db不一致，从而导致服务发生错误。
避免措施：
原则：合并存在修改db的代码前必须进行数据同步，否则就不能合并；整个过程开发人员是驱动者，驱动整个流程进行；运维人员需要特别关注代码和db的状态一致性，可以询问相关的开发和测试获知，也可以自己找办法记录；
- 处理合并代码事务，提前解决潜在的冲突，补充合并备注等内容。（如果在此步骤提了合并请求，一定要标注WIP防止无合并，并在合并内容中说明存在修改db的行为）
- 在合到sbeta之前，开发人员（组长或者具体代码开发人员）找代码需求相关的产品经理或测试人员询问，是否需要同步生产数据进行测试
? 如果需要：
? 开发告知运维需要先同步数据到sbeta，然后再告知合代码的人合并代码
? 如果不需要：
? 开发告知运维直接合并代码到sbeta，注意，此时如果后续有db同步的行为，可能导致db和代码不一致从而服务错误。（这种状态需要此时的开发、测试和运维共同知晓，防止后续错误的状态处理）
|