如何在微服务团队中高效使用 Git 管理代码？

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



话不多说，直接上问题：如何在微服务团队中高效使用 Git 管理代码？



继续不多话，直接上答案：分支管理。



<!--more-->



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



• TrunkBased：主干在手，天下我有。所有代码都往主干上招呼，发版也只用主干。

• GitFlow：严谨、规范、难用，主要是记不住该往哪个分支合并了。

• AoneFlow：前两种都不行，那就借鉴各自的优点，达到阴阳平衡，中庸也。



TrunkBased



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



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





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



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



GitFlow



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



先上图：





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 相似，主干分支上的最新版本始终与线上版本一致，如果要回溯历史版本，只需在主干分支上找到相应的版本标签即可。





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



再啰嗦几句废话



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