git并行开发工作流说明

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，不一定是优先上线的）

1. A先行合到dev进行联调，不需要关注B的情况。

2. A分支开发完，合到dev供联调，联调中禁止merge dev into A。

3. dev修复A相关的bug时，在A上修复完merge A into dev。如果有冲突，及时解决dev上的冲突。

4. 重复3直至联调完毕。

B视角流程（优先上线分支视角）

1. 由于流程上A将优先进入提测，但B先于A上线，则禁止merge A into B，以防被污染。

   B如果不优先上线，而且需要感知A所有已提交的代码，那么需要merge A into B。

2. merge B into dev，期间禁止 merge dev into B，以防被污染。

   B如果不优先上线，而且需要感知dev中已提交的代码，那么需要merge A into B。注意dev中含有的未经beta测试的代码的影响。

3. 同A的修复流程，修复自己bug，如有冲突及时解决dev上的冲突。

   如果A中修复了bug，B可以根据需要是否cherry-pick（这里根据对A的依赖程度谨慎考虑是否需要merge）。

4. 重复3，直至联调完毕。

提测

A视角（先行开发分支视角）

1. 联调完毕提测时，拉取beta 最新代码：git checkout beta & git pull

2. 建立预备分支，解决冲突。

   Tips：冲突简化流程的条件：

   • 如果确定没有冲突，可以直接merge A into beta。或

   • 如果A并不关注beta对A的代码污染，可以和现有beta 代码一起提测上线，那么可以选择merge beta into A解决冲突完后，pull requests: merge A into beta

   1. git checkout beta_A from beta
   2. 在本地merge A into beta_A，解决冲突后，pull requests: merge beta_A into beta。

3. beta修复A相关的bug时，在A上修复完，merge into Beta_A，然后pull requests: merge Beta_A into beta。

   Tips：冲突简化流程的条件：

   • 2中没有建立预备分支，如果确定没有冲突，可以直接merge A into beta。或

   • 如果A并不关注beta对A的代码污染，可以和现有beta 代码一起提测上线，那么可以选择merge beta into A解决冲突完后，pull requests: merge A into beta

4. 重复3，直至通过提测。

5. 通过提测后，merge beta into A，merge beta into dev，使dev上获得最新可靠的代码。

B视角（优先上线分支视角）

1. 如果B需要先于A提测上线，则不需要mergeA。

   假设B不是优先上线的分支，如果A已经提测，根据对A的依赖，考虑是否需要先merge A into B，防止后续更多的冲突。

   如果A已经通过了提测，推荐此时merge A into B，除非B对污染程度要求特别高，不希望任何代码的干扰。

2. 更新本地最新的beta代码。

3. 建立预备分支解决冲突:

   1. checkout Beta_B from beta
   2. merge B into Beta_B
   3. pull requests: merge Beta_B into Beta

   Tips：冲突简化流程的条件：

   • 如果确定没有冲突，可以直接merge B into beta。仅在有冲突时采用3中给出的流程。

4. beta修复B相关的bug时，在B上修复完merge into beta。如果有冲突参考2和3.

5. 通过B相关提测后，

   1. 更新dev：merge beta into dev。由于B需要防污染，这里不要merge beta into B。但仍需要使dev保持最新。

   2. 更新仿真：merge sbeta21 into B，解决冲突后，merge B into sbeta21.

      如果确定无冲突，可以直接 merge B into sbeta21。

   3. 更新master: merge sbeta21 into master.

      流程需要确保这里总是没有冲突。

      sbeta21到master的流向只有在发生bug时可能会产生短期的不一致，需要修复bug的分支往上游分发。

仿真数据同步与代码合并流程注意事项

问题描述：

提往sbeta分支的代码如果有flyway脚本修改了db数据或者结构， 在代码合并到sbeta后，因为可能会有同步生产db到仿真的行为，导致仿真的代码和db不一致，从而导致服务发生错误。

避免措施：

原则：合并存在修改db的代码前必须进行数据同步，否则就不能合并；整个过程开发人员是驱动者，驱动整个流程进行；运维人员需要特别关注代码和db的状态一致性，可以询问相关的开发和测试获知，也可以自己找办法记录；

1. 处理合并代码事务，提前解决潜在的冲突，补充合并备注等内容。（如果在此步骤提了合并请求，一定要标注WIP防止无合并，并在合并内容中说明存在修改db的行为）
2. 在合到sbeta之前，开发人员（组长或者具体代码开发人员）找代码需求相关的产品经理或测试人员询问，是否需要同步生产数据进行测试

​ 如果需要：

​ 开发告知运维需要先同步数据到sbeta，然后再告知合代码的人合并代码

​ 如果不需要：

​ 开发告知运维直接合并代码到sbeta，注意，此时如果后续有db同步的行为，可能导致db和代码不一致从而服务错误。（这种状态需要此时的开发、测试和运维共同知晓，防止后续错误的状态处理）