美文网首页Android
代码分支管理

代码分支管理

作者: 落影loyinglin | 来源:发表于2022-04-03 08:50 被阅读0次

    前言

    没有最好的代码管理方式,只有最适合当前需求的方式。

    正文

    移动项目中,有用SVN做代码管理,也有用Git。从效率上来讲,Git会比SVN更优:最直接的是SVN在切换分支时比较慢。
    为了适应敏捷开发的快速迭代,代码管理工具大体都在慢慢切向Git。
    本文是介绍项目中用Git管理代码分支遇到的问题。

    项目初期

    用Git管理代码,首先要区分分支,最直接的做法是仅提供两个分支:
    为了保持开发阶段的便利,提供develop分支,作为日常开发的提交分支;
    为了保证外网代码的可查,提供master分支,作为日常发布的打包分支;
    当版本发布之后,还需要打tag记录对应版本,比如说release_1.0.0.10。(版本号通常为3位,第四位是build号,用于苹果审核时对同版本的不同二进制版本做一个区分)

    随着版本迭代,有两个新的诉求出现:
    1、code review,每个版本的新增代码要经过review再发布,以控制版本质量;
    2、版本灰度的需要,并且可能会有一灰、二灰、三灰等多次灰度;

    最初使用的是cherry-pick功能,在develop分支的代码以需求作为维度,当某个需求做完(QA验收通过)之后,就可以通过cherry-pick的方式将代码提到一个master的分支,再走merge request的方式合入master,此时reviewer可以review本次提交的代码并同意合入分支。

    这样好处是可以仅保留两个分支,需求的开发、测试和验收都在develop分支,灰度的bugfix都在master分支进行。在项目早期测试和验收人力非常宝贵的情况下,同一条分支验收可以兼顾多个需求,较大程度提高验收效率;而且初期参与写代码的研发就寥寥数人,统一分支开发也是方便研发同时对多个需求同时进行开发和问题修复,最大程度利用研发人力。

    项目稳定

    随着项目逐渐复杂和稳定下来,开始暴露一些问题:每个版本的需求往往是到版本末期才合入,导致develop分支在后期cherry-pick的时候容易产生冲突,因为某个类在版本后期可能有多个人修改;同时版本末期的review时间也比较少,此时集中的多个merge request会造成review的困难;对QA来说,合码冲突中造成的Bug非常不可控,因为该需求已经验收完毕,结果合码产生了新的Bug,导致回归测试的时间变长。

    各方要求:

    • RD诉求:
      开发阶段,可以自由提交代码;
      代码合并阶段,功能可以拆分review;
      验收阶段,修改可以方便同步给QA和UI;
      灰度阶段,所有代码需要走MR;

    • QA诉求:
      测试阶段,bug修复要及时且不要被其他需求影响;
      回归阶段,回归核心功能和当前版本变动点;
      发版阶段,只需要过checklist;

    • UI/DA/UE/PM诉求:
      验收阶段:方便验收,条件简单;
      回归阶段:提前发现需求冲突的问题;

    综合多方述求,从产品质量和研发效率角度出发,兼顾质量稳定和业务迭代效率,保留需求的开发、测试、验收流程比较便捷,切换到多分支的管理模式。

    多分支管理

    一句话概括:关闭develop和master分支的push功能,保留merge request能力阶段采用拉分支,各个需求单独分支开发,测试验收通过之后再合入develop。

    需求开发阶段:每个人拉出需求分支,分支内任意提交;
    测试验收阶段:需求分支验收需求,必要的单独配置测试环境;
    代码合并阶段:分支上的代码提merge到develop分支;
    灰度阶段:只允许合入bug修复,其他延后下个版本;
    提审阶段:最后一个灰度的代码进行打包提交,添加tag;

    合码规范

    提交类型

    • feature--需求类型,分支名以feature_需求名作为开头;
    • bugfix-具体bug,分支名以bugfix_具体bug作为开头;

    冲突解决
    分支在提merge request的时候会发生冲突,此时需要解决冲突:
    1、以feature_test_merge为例,先拉下来feature_test_merge分支;
    2、在分支feature_test_merge拉取目标分支的代码,这里以master为例:

    找到冲突的文件,解决完冲突将文件标记为已解决,最后提交合并解决冲突;

    如果可以,尽量使用rebase;因为rebase完之后,分支的提交会更加清晰,否则git提交记录处可能会有很多条线。

    总结

    不管是developer分支集中开发再cherry-pick到beta分支,还是多分支管理的模式都有各自的优缺点,只能说在项目合适的时期选用适当的方式。
    代码的分支管理会随着项目迭代不断进行优化,总体来说是往两个方向发展:保证版本的质量,以及提高开发的效率。

    在修改这篇文章的时候颇有感触,文章提到的项目初期真的是很早以前的事情了。
    随着项目逐渐发展,分支管理已经逐渐习以为常,现在大家关注的都是组件化多仓管理和多仓合码,pipeline包大小检测、安全检测、覆盖率检测、单元测试等等。

    相关文章

      网友评论

        本文标题:代码分支管理

        本文链接:https://www.haomeiwen.com/subject/osrnxctx.html