较大型前端项目git管理方案

分支管理

• release分支：正在线上运行的分支

• release_[node]分支：【可选】node为节点名，以release分支为基准切

  • 区分节点的【小程序】【综合管理平台】需要拉此分支，不区分节点不需要拉，综合管理平台不需要的情况也可以不拉

  • 此分支是给新节点上线用，有新节点需要上线时，以release分支为基准来切此分支，该节点无bug无问题上线后，将此分支合并回release分支，此分支删除

  • 此分支上线期间，release分支有bug修复，将release分支合并至当前分支，绝对不可逆向合并

  • 此分支上线过程中，测试发现了bug，此bug属于其他节点也有的bug，该bug在release分支进行修改，修改完成执行上条操作

  • 此节点有属于自我的功能，例如：洛阳和上饶的院内导航是文章，但南昌二附院院内导航需要跳转到自己的地址，此修改在当前分支修改，同时需要兼容洛阳和上饶

  • 此节点上线完成稳定后，将此节点合并回release分支，此节点删除

  • 此节点合并回release分支时，发现release分支有新的功能加入，但本次上线此节点并未上线该功能，先将release分支合并至当前节点，无冲突后，在合并回release分支，此分支删除

  • 合并回release分支之后，新功能在当前节点永不上线，在release分支修改此节点配置，做兼容处理（此节点已删除）

  • 特殊情况：此分支上线过程中，测试发现了bug，此bug属于其他节点也有的bug，理应在release分支修改后合并至当前分支，但此时release分支有新功能加入，新功能当前节点并不上线，此时的bug需要在release分支和当前分支修改两次。（合并回release分支时会有冲突，所以需要合并时先将release分支合并到当前分支，解决冲突后再合并回，然后此分支删除）

• 业务分支：业务分支为新的开发的功能分支，此分支以release分支为基准切

  • 【分支命名】：业务名拼音缩写_dev 例如在线问诊：**zxwz_dev**

  • 业务分支测试完成且产品验收后将业务分支合并至dev分支

  • 业务分支开发过程中，每天将release分支往业务分支合并一次，但是绝对不可以将业务分支往release分支合并 (这样做的原因是避免最终此业务进行测试时，由于其他业务的bug，被测试发现了，然后提给此业务的开发人员，造成时间浪费；或者由于其他业务的bug阻塞此业务的测试)

  • 业务分支合并至dev分支后，业务分支可删除也可保留，保留是为了方便溯源，也没有其他用处

  • 业务功能等待上线的过程中，测试有可能会发现其他bug，此时业务的bug修复，以dev为基准去切分支修复，修复完成后合并回dev分支，测试验收后，切出去的分支删除

  • 如果没有其他情况（指业务分支_测试分支），业务分支既是开发分支也是用来测试的分支

• 业务分支_测试分支：【可选】此分支在在需要的情况下切，以业务分支为基准

  • 【分支命名】：业务名拼音缩写_test 例如在线问诊：**zxwz_test**

  • 业务分支是1.0版本，此时正在测试阶段，产品对1.0做出了迭代1.2的版本，1.0版本需要优先上线，1.2版本可以逐渐开发，此时我们不能在业务分支直接开发1.2版本，这样会对1.0版本产生严重影响，甚至造成1.0版本无法上线。此时需要以业务分支为基准切出测试用的1.0版本分支（也就是当前分支），然后在业务分支开发1.2版本

  • 当测试在此分支测试出bug时，需要先判断此bug在1.2的版本是否会存在，

    • 如果不存在，以此分支为基准，切出一个修改bug的分支，修复完成后合并回此分支。测试验收通过后，切出去的分支删除掉

      此时之所以以此分支为基准切分支去改bug，而不是在个人业务分支直接去改bug后合并过来的考虑为，个人业务分支此时需要开发1.2的版本，个人分支上有1.2版本的代码，故需要切新分支去修复。

    • 如果在1.2版本也存在，参考 【业务分支 and 业务分支_测试分支 改bug分支：】

• 业务分支 and 业务分支_测试分支 改bug分支：【可选】业务分支和业务分支 _测试分支 用来改公共bug的分支，在切业务分支 _测试分支时同步以业务分支为基准切此分支，场景如下

  • 【分支命名】：业务名拼音缩写_common_hotfix 例如在线问诊：**zxwz_common_hotfix**

  • 业务分支为1.2版本。业务分支_测试分支为1.0版本。

    两个分支有公共的底层部分，此时一个正在开发中一个正在测试中，测试在测试过程中发现了bug，此bug属于底层bug，在1.2版本和1.0版本都有。

    此时如果bug在业务分支 _测试分支修改，修改后合并到业务分支此时会出现这种问题：测试分支的部分bug已修复，也已合并到测试分支，但是这部分bug在1.2版本上不可能出现（这部分出现bug的场景条件土壤已经被产品删除了），直接合并就会导致这些代码与1.2版本冲突，1.2又需要删除这些内容。（这部分逻辑已经在1.2被完全改了，合并过去会对1.2产生严重影响，小影响就是产品大量冗余代码）

    同理在业务分支1.2版本修改后合并测试分支也会出现1.2的新逻辑代码和1.0产生影响。

    基于此，建议在切测试分支时也同步再切出此分支。此分支代码落后于测试分支也落后于开发分支，所以在此分支修改公共bug后，合并到测试和开发分支产生问题较小

    当然此分支根据实际情况来决定是否切，如果1.0已经测试尾声，不会出现底层问题，此分支可以不切。

    决定底层代码在业务分支和测试分支修改两次，也可以不切。

    根据实际情况使用来决定此分支是否切，一切以方便开发产生最少bug为原则

• 耦合业务测试分支：【可选】以dev为基准拉。适用场景如下

  • 【分支命名】：**common_business_test**

  • A、B、C三个业务耦合，需要联合测试，但我们的基准是各业务在业务分支测试完合并到dev分支，也就是分开测试，耦合的业务联合测试是无法满足的。

    此时可以以dev分支为基准，切耦合业务测试分支，三个业务合并至此分支，测试完成，再由业务分支合并至dev分支。

    A业务测试完，产品已验收，B、C业务没测试完，此时A业务也可以直接合并至dev分支。

    轻度耦合的，A业务提测，B业务未全部完成，但耦合部分不影响，此时A、B可以合并到此分支，主测A业务和耦合部分，A业务测试完成，产品验收后直接合并dev分支（需要了解上线时间，参见其他场景二的说明）

    PS： 耦合节点测试分支主要供耦合的业务测试使用，最终是由业务分支合并到dev分支的，不是由耦合测试分支合并到dev的，一定需要清楚

  • 此分支测试完成后及时删除，下次再出现此场景需要，再重新拉即可

  • 耦合业务测试分支的bug，在个人分支修改，修改完成后合并到业务分支，再由业务分支合并到此分支。也可以在业务分支直接修改，修改完成合并到耦合业务测试分支。但是禁止在个人分支修改后直接合并耦合业务测试分支

  • 此分支之所以选择以dev为基准而不是以release为基准的考虑是，风险问题前置，业务分支最终是要往dev分支合并的，与其最终合并时解决冲突或者其他问题，不如提前解决

• 多业务公共部分（比如公共组件）开发分支：【可选】此分支以release分支为基准切

  • 【分支命名】：**common_business_dev**

  • 多个业务开发过程中，有用到了相同的组件或者插件，此时可以以release分支为基准，切此分支，来进行开发公共部分开发，开发完成后合并到需要用到的业务分支；（更具体的说明见其他场景一）

  • 此分支只供多业务的公共部分开发使用，使用完毕后删除

  • 之所以没有用此分支作为整个项目的公共部分开发分支使用的考虑是：我们不会每天都在开发公共部分，只会在用到公共部分的时候去使用，如果作为整个项目的公共部分分支，我们就必须维护此分支，不能使此分支代码落后太多，有维护成本。

    如果代码落后太多上百个版本，再次使用的时候，需要从release拉最新代码，合并。上百个版本势必会有冲突，与其花时间去解决冲突，不如使用的时候直接再拉个分支，会更加方便

  • 此节点其实也可以作为耦合节点测试分支来使用。但是 我们写代码都希望每个函数只做一件事，但一原则，那么在此，也希望可以使用单一原则来处理，每一个分支只做一件事。所以有两个差不太多的分支

• dev分支：dev分支为等待上线的分支，所有业务功能产品验收后会合并到此分支

  • 已经合并到此分支的业务发现bug，以dev为基准切分支进行修复，遵循业务分支说明第四条（即下方内容）
  • 业务功能等待上线的过程中，测试有可能会发现其他bug，此时业务的bug修复，以dev为基准去切分支修复，修复完成后合并回dev分支，测试验收后，切出去的分支删除
  • dev要上线，将dev合并到release分支，release分支配置好，在合并到master，由master发版。（如果之后有了预发布环境，dev合到release，release上预发布环境，完全没有问题后，合master，master分支发版）

• 个人分支/个人开发分支：个人分支建议以业务分支为基准切，

  • 【分支命名】：姓名缩写_业务拼音名缩写 例如：张三开发在线问诊 zs_zxwz

  • 如果个人同时开发多个业务功能，请以各业务分支为基准建多个个人分支，不允许一个个人分支同时开发多个业务 （之所以这样规定，是为了保证各个业务分支的纯洁性，否则可能会出现A业务测试过程中，B业务的代码乱入造成不可预知的问题）

  • 个人分支仅允许与业务分支互相合并

  • 业务测试过程中发现的bug，提到具体个人，在个人分支修改后合并到业务分支

  • 待上线/已上线的bug修复，遵循该分支bug修复说明，禁止在个人分支修改后合并到对应分支，绝对禁止

• master分支：release分支每一次需要发版时，将release分支合并至master分支，最终由master分支发版。

  • release分支为线上稳定版代码

• Tag版本：

  • 新节点上线，最终以release_[node]分支上线，上线后以release _[node]打Tag
  • 稳定版节点上线，由release合并到master，master发版之后，以master打Tag

##其他场景

1. A、B、C三个业务在同时开发中，ABC三个业务用到了同样的公共组件，同一个插件等有同样内容的部分，如何处理？

   ​ A、B、C三个业务都在开发中，开发中的业务，每天必须将release分支的代码合并过来，说明A、B、C三个业务的基准是一样的。

   ​ 为了保证A、B、C三个业务的纯洁性，公共部分在任何一个分支开发，然后同步到另外两个业务，都是不合适的。

   ​ 所以、为了保证纯洁性，避免污染和影响，以release分支为基准，再拉一个分支，再此分支开发公共部分，组件插件等，开发完成之后，将此分支合并到A、B、C三个业务分支，此来新拉出来分支不会有开发中的业务，有的只是三个业务的公共内容，合并到业务分支后，业务分支也可以最大程度保证纯粹性

   ​ 缺点：麻烦，加入A、B、C三个业务只是需要一个公共的插件，但需要先拉分支引入，在合并，麻烦

   • 决定拉分支，多业务公共部分开发分支

2. A、B、C三个业务在同时开发中，ABC三个业务有部分耦合/低耦合，ABC三个业务可分开上线，A业务要往B业务的某个页面跳转等情况，如何处理？

   ​ B业务给A业务提供路径，入参等内容，A业务进行处理，此时可能跳转不过去，但代码同步到dev后不会出现此问题，测试过程中需要给测试进行解释说明（这里已经有耦合业务测试分支来解决）

   ​ A业务产品已经验收，即将往dev分支合并，此时B业务尚未开发完成，先了解A业务上线时间，A业务上线时B业务是否可以完成验收合并到dev分支？

   ​ 如果A业务上线时，B业务可以验收完成合并到dev分支，那A业务直接合并到dev分支

   ​ 如果A业务上线时，B业务还未测试完成验收，不能合并至dev分支，对于耦合部分的处理，是隐藏掉或者其他处理，与产品进行沟通，沟通完成之后在业务分支处理完成之后在合并到dev分支

3. A、B、C三个业务在同时开发中，ABC三个业务严重耦合，三个业务需要同时上线，如何处理？

   ​ 耦合性非常高的三个业务，强烈建议作为一个业务开发，建一个业务分支，人员多点分支管理方案可以处理

   ​ 最好从根源解决

讨论点

1. 是否需要拉release_[node]分支？

   不拉的优点：

   • release_[node]分支最终要合并入release分支，直接在release分支修改更方便；_
   • 拉release_[node]分支后，有可能会出现同时在release和release_[node]分支修改两份的情况
   • 公共部分出bug后，需要切回release分支修改后同步回release_[node]分支，来换切换分支不如直接在release分支做修改

   拉的优点：

   • 如果同时有两个节点要上线，切出release_[node]分支修改更方便，两个节点影响会更小；（但在release分支修改，直接做了兼容处理，免去合并回的时候解决冲突）
   • 如果上线时间紧，切出去修改，省略了兼容处理，节省时间，上线之后合并回的时候再做兼容处理
   • 如果不拉分支，新节点（release_[node]）上线期间，老节点（release）要发版，影响会很大；

   最终结论：拉release_[node]分支，相较于不拉分支的优点，减小新旧节点互相发版造成的影响更为重要

2. 业务分支以release分支为基准切，还是以dev分支为基准切

   • release（暂定）

3. 有轻度耦合的三个业务同时开发，是在业务分支提交测试，还是开发完成后合到dev分支提测？dev做等待发布上线的分支，还是测试分支？

   如果业务分支以dev为分支切，dev作为测试分支，有轻度耦合（公用组件，插件）的业务，就可以直接在dev做公共部分，然后业务去合并dev分支。（完全可以，但总感觉不是特别好）

   最终结论：之所以存在这个问题的原因是，耦合业务最好的结果是联合测试，但是分了业务之后各业务都在业务分支开发测试，联合测试放到dev并不是特别合适，在业务分支分开测，有无法提供充足的安全感。但当有了耦合业务测试分支之后，就可以多业务合并此分支测试，完成后业务分支合并至dev分支。此问题也就不存在了

4. master怎么定位？合并什么代码？

   release分支为稳定版代码，每一次需要发版时，在release分支全部更新配置完成，合并至master分支，最终由master分支发版。master分支为稳定版本最终上线的输出

   不区分节点的医生web和超管端，虽然不需要在release分支配置更新，但依旧要求由release合并至master来发版上线