如何在足够规模团队中高效使用 Git 管理代码?

用了 Git 多年,优势和挑战都是深有体会。

话不多说,直接上问题:如何在足够规模团队中高效使用 Git 管理代码?

继续不多话,直接上答案:分支管理。

Git 的分支管理有很多实践,有些是从 SVN 类的集中式版本管理工具继承的,有些是根据 Git 自己的特性总结的,目前市面上比较有名的三种 Git 分支管理模型是:

  • TrunkBased:主干在手,天下我有。所有代码都往主干上招呼,发版也只用主干。
  • GitFlow:严谨、规范、难用,主要是记不住该往哪个分支合并了。
  • AoneFlow:前两种都不行,那就借鉴各自的优点,达到阴阳平衡,中庸也。

TrunkBased

TrunkBased,又叫主干开发,有一个网站专门介绍这种开发方式:Trunk Based Development。

TrunkBased 是持续集成思想所崇尚的工作方式,它由单个主干分支和许多发布分支组成,每个发布分支在特定版本的提交点上从主干创建出来,用来进行上线部署和 Hotfix。在 TrunkBased 模式中,没有显性的特性分支。当然实际上 Git 的分布式特征天生允许每个人有本地分支,TrunkBased 也并非排斥短期的特性分支存在,只不过在说这种模式的时候,大家通常都不会明确强调它罢了。

TrunkBased

使用主干开发后,我们的代码库原则上就只能有一个 Trunk 分支即 master 分支了,所有新功能的提交也都提交到 master 分支上,保证每次提交后 master 分支都是可随时发布的状态。没有了分支的代码隔离,测试和解决冲突都变得简单,持续集成也变得稳定了许多。

但是这种方案缺点也比较明显,如果大家都在主干进行开发,当代码提交合并时,将会异常痛苦,一不小心就会出现冲突。而且,这种因为这种方式没有明显的特性分支,想要移除已经上线的特性会变得非常困难。(如果你说把不要的功能注释,重新发版,那就当我什么也没说。)还有一种方案是引入特性开关,通过开关控制特性是否启用和关闭,但是增加开关就引入了复杂性,引入复杂性就引入了出 bug 的风险,毕竟多增加的每行代码都有可能是一个新的 bug。

GitFlow

GitFlow 来源于 Vincent Driessen 提出的 A successful Git branching model,整体来说,是一套完善的版本管理流程。缺点就是太过严格,不太适合喜欢自由而且懒的程序猿。当然,在程序猿这种物种中,没有完美的解决方案,总有那么一小撮人会觉得不好。参考 Ant、Maven 和 Gradle。

先上图:

GitFlow:A successful Git branching model

GitFlow 常用分支:

  • 主干分支(master):最近发布到生产环境代码的分支,这个分支只能从其他分支合并,不能再 Master 分支直接修改。
  • 主开发分支(develop):包含所有要发布到下一个 Release 版本的代码。可以在 Develop 直接开发,也可以将 Feature 的特性代码合并到 Develop 中。
    主开发分支
  • 特性分支(feature/*):功能项开发分支,以feature/开头命名分支,当功能项开发完成,将被合并到主开发分支进入下一个 Release,合并完分支后一般会删点这个特性分支。
    特性分支
  • 发布分支(release/*):基于主开发分支创建的一个发布分支,以release/开头命名分支,用于测试、bug 修复及上线。完成后,合并到主干分支和主开发分支,同时在主干分支上打个 Tag 记住 Release 版本号,然后可以删除发布分支。
    发布分支
  • 热修复分支(hotfix/*):用于解决线上 Release 版本出现的 bug,以hotfix/开头命名分支,修复线上问题,完成后,合并到主干分支和主开发分支,同时在主干分支上打个 tag。
    热修复分支

根据上面描述,GitFlow 是一套完整的从开发到生产的管理方式,但是各种分支来回切换及合并,很容易把人搞晕,所以用的人也是越来越少。

AoneFlow

AoneFlow 是阿里内部的一套版本管理模型,兼顾了 TrunkBased 易于持续集成和 GitFlow 易于管理需求的特点,又规避了 GitFlow 分支繁琐的缺点,也就是中庸。

AoneFlow 使用三个分支:主干分支(master)、特性分支(feature/*)、发布分支(release/*),以及三条原则:

规则一,开始工作前,从主干分支创建特性分支。

这条规则借鉴了 GitFlow,每当开始一件新的工作项(比如新的功能或是待解决的问题,可以是一个人完成,或是多个人协作完成)时,从代表最新已发布版本的主干分支上创建一个通常以feature/前缀命名的特性分支,然后在这个分支上提交代码修改。也就是说,每个工作项对应一个特性分支,所有的修改都不允许直接提交到主干。

从主干创建特性分支

特性分支不止承担了新功能,也是待解决问题的分支。对于我们团队,为了避免歧义,会将新功能以feature/为前缀,待解决问题以hotfix/为前缀,除了名称外,其他都按照规则一执行。

规则二,通过合并特性分支,形成发布分支。

GitFlow 先将已经完成的特性分支合并回主干分支和主开发分支,然后在主干分支上打 Tag 记录发布信息。TrunkBased 是等所有需要的特性都在主干分支上开发完成,然后从主干分支的特定位置拉出发布分支。而 AoneFlow 的思路是,从主干上拉出一条新分支,将所有本次要集成或发布的特性分支依次合并过去,从而得到发布分支,发布分支通常以release/前缀命名。

合并特性分支,形成发布分支

我们可以将每条发布分支与具体的环境相对应,release/test对应部署测试环境,release/prod对应线上正式环境等,并与流水线工具相结合,串联各个环境上的代码质量扫描和自动化测试关卡,将产出的部署包直接发布到相应环境上。

另外,发布分支的特性组成是动态的,调整起来特别容易。在一些市场瞬息万变的互联网企业,以及采用“敏捷运作”的乙方企业经常会遇到这种情况,已经完成就等待上线的需求,随时可能由于市场策略调整或者甲方的一个临时决定,其中某个功能忽然要求延迟发布或者干脆不要了。再或者是某个特性在上线前发现存在严重的开发问题,需要排除。按往常的做法,这时候就要来手工“剔代码”了,将已经合并到开发分支或者主干分支的相关提交一个个剔除出去,做过的同学都知道很麻烦。在 AoneFlow 模式下,重建发布分支,只需要将原本的发布分支删掉,从主干拉出新的同名发布分支,再把需要保留的各特性分支合并过来就搞定,而且代码是干净的,没有包含不必要的特性。

此外,发布分支之间是松耦合的,这样就可以有多个集成环境分别进行不同的特性组合的集成测试,也能方便的管理各个特性进入到不同环境上部署的时机。松耦合并不代表没有相关性,由于测试环境、集成环境、预发布环境、灰度环境和线上正式环境等发布流程通常是顺序进行的,在流程上可以要求只有通过前一环境验证的特性,才能传递到下一个环境做部署,形成漏斗形的特性发布流。当然,这种玩法比较适合有完整开发集成平台的公司,小团队玩不转,比如我们团队就玩不动这种高级玩法。

规则三,发布到线上正式环境后,合并相应的发布分支到主干,在主干添加 Tag,同时删除该发布分支关联的特性分支。

当一条发布分支上的流水线完成了一次线上正式环境的部署,就意味着相应的功能真正的发布了,此时应该将这条发布分支合并到主干。为了避免在代码仓库里堆积大量历史上的特性分支,还应该清理掉已经上线部分特性分支。与 GitFlow 相似,主干分支上的最新版本始终与线上版本一致,如果要回溯历史版本,只需在主干分支上找到相应的版本标签即可。

合并相应的发布分支到主干,在主干添加 Tag,同时删除该发布分支关联的特性分支

除了基本规则,还有一些实际操作中不成文的技巧。比如上线后的热修复,正常的处理方法应该是,创建一条新的发布分支,对应线上环境(相当于 Hotfix 分支),同时为这个分支创建临时流水线,以保障必要的发布前检查和冒烟测试能够自动执行。

再啰嗦几句废话

不管哪种方式,既然存在,都会有一定合理性。所以,不管最终翻了哪个牌子,不是因为这个好看,而是因为这个更适合自己。


个人主页:https://www.howardliu.cn
个人博文:如何在足够规模团队中高效使用 Git 管理代码?
CSDN 主页:http://blog.csdn.net/liuxinghao
CSDN 博文:如何在足够规模团队中高效使用 Git 管理代码?

你可能感兴趣的:(如何在足够规模团队中高效使用 Git 管理代码?)