大型前端项目git管理方案

为什么要有它

为什么要有它？肯定是我们项目遇到问题了，所以根据实际情况约定下的解决方案。

首先说下我们的项目，我们的项目是一个提供给医院来使用的系统，包含Web与小程序与App端....，本文主要针对我们Web与小程序。

我们项目是一个多人协作开发的项目，参与开发人员有十好几个，在开发过程中我们出现了以下问题。

背景一： dev分支是我们开发分支，每位开发人员每天下班后都需要将自己分支合并到dev分支上，dev分支上拥有最新的代码。

背景二： 每个业务功能的开发都是多个人一起开发，每个开发人员在自己的个人分支开发，每天下班将个人分支合入dev分支，第二天上班拉取dev分支合入个人分支后再开始开发。

背景三： 我们系统是基于配置的，每家医院所需要的功能并不一定全部一样，所以会给每家医院提供不同的配置，根据配置来编译打包，最终得到不一样的功能的系统，每家医院所用的系统都部署在不同的服务器上。

背景四： release分支是我们发版分支

• 【问题一】 A业务与B业务都在开发中，A业务开发完成了，需要移交测试，从dev分支发布测试环境；但是B业务没有开发完成，哪怕B业务不会对A业务造成影响，A业务测试通过后也无法发布上线，因为B业务没有开发完成没有测试完成，系统功能不完整。
  • 【衍生问题】 另外dev分支作为开发分支，每天都会有其他开发人员往dev合入代码，A同学的代码没有对A业务造成影响，但是如何保证BCDEFG同学的代码不会对A业务造成影响
• 【问题二】 系统正常升级，需要给所有在使用的医院都升级到。ABC医院都是老用户，之前一直在使用这个系统，D医院刚加入进来。此时需要给D医院来添加配置，配置D医院的logo，D医院的名称；除此之外D医院还提出了其他的一些要求，我们需要添加新的配置选项，来对ABC三家医院作兼容。添加了配置之后我们必须再测试一波确保满足D医院的需求，同时没有出现新的bug。但是这样就会出现一个问题，如果在release修改配置，配合测试，势必会影响ABC的正常发版。
  • 【衍生问题】 且如果测试过程中，此时线上环境出现了紧急bug，需要紧急修复上线，在release修改会阻塞bug的修复上线。
  • 【衍生问题】 测试过程中，新的业务功能测试通过了，需要发布上线，但新节点（也就是D医院）还在测试，会造成新功能堆积无法正常上线。

最后这个方案也是我们项目正在使用的管理方案，它并没有很完美，如果你的项目中出现了类似的问题，希望这个方案可以给你提供一些解决思路。

背景名词

node/节点： 下文所有提到的的node或者节点，均指使用这个系统的客户(医院)

分支管理

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

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

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

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

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

  • 此节点有属于自我的功能，例如：A节点和B节点的地图导航(系统的一个功能)是文章，但C节点的地图导航需要跳转到自己的地址，此修改在当前分支修改，同时需要兼容A节点和B节点

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

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

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

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

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

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

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

  • 业务分支测试完成且产品验收后，如果需要立即上线，可以将此分支合并至release分支，如不需要立即上线，将此分支分支合并至dev分支；在此业务成功上线之前，此业务分支不能删除，业务成功上线之后，此分支可以删除。
  • 业务功能等待上线的过程中，测试有可能会发现其他bug，此时业务的bug修复，以dev为基准去切分支修复，修复完成后合并回dev分支，测试验收后，切出去的分支删除
  • 如果没有其他情况（指业务分支_测试分支），业务分支既是开发分支也是用来测试的分支

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

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

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

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

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

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

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

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

  • 【分支命名】：业务名拼音缩写_common_hotfix 例如在线问诊：yewu_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三个业务严重耦合，三个业务需要同时上线，如何处理？

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

   ​ 最好从根源解决