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

{"type":"doc","content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"用了 Git 多年，优势和挑战都是深有体会。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"话不多说，直接上问题：如何在微服务团队中高效使用 Git 管理代码？"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"继续不多话，直接上答案：分支管理。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":""}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"Git 的分支管理有很多实践，有些是从 SVN 类的集中式版本管理工具继承的，有些是根据 Git 自己的特性总结的，目前市面上比较有名的三种 Git 分支管理模型是："}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"bulletedlist","content":[{"type":"listitem","content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"TrunkBased：主干在手，天下我有。所有代码都往主干上招呼，发版也只用主干。"}]}]},{"type":"listitem","content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"GitFlow：严谨、规范、难用，主要是记不住该往哪个分支合并了。"}]}]},{"type":"listitem","content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"AoneFlow：前两种都不行，那就借鉴各自的优点，达到阴阳平衡，中庸也。"}]}]}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"heading","attrs":{"align":null,"level":2},"content":[{"type":"text","text":"TrunkBased"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"TrunkBased，又叫主干开发，有一个网站专门介绍这种开发方式："},{"type":"link","attrs":{"href":"https://trunkbaseddevelopment.com/","title":""},"content":[{"type":"text","text":"Trunk Based Development"}]},{"type":"text","text":"。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"TrunkBased 是持续集成思想所崇尚的工作方式，它由单个主干分支和许多发布分支组成，每个发布分支在特定版本的提交点上从主干创建出来，用来进行上线部署和 Hotfix。在 TrunkBased 模式中，没有显性的特性分支。当然实际上 Git 的分布式特征天生允许每个人有本地分支，TrunkBased 也并非排斥短期的特性分支存在，只不过在说这种模式的时候，大家通常都不会明确强调它罢了。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"image","attrs":{"src":"https://static001.geekbang.org/infoq/12/12f50392f5238664900be052ca37619d.jpeg","alt":"TrunkBased","title":null,"style":null,"href":null,"fromPaste":true,"pastePass":true}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"使用主干开发后，我们的代码库原则上就只能有一个 Trunk 分支即 master 分支了，所有新功能的提交也都提交到 master 分支上，保证每次提交后 master 分支都是可随时发布的状态。没有了分支的代码隔离，测试和解决冲突都变得简单，持续集成也变得稳定了许多。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"但是这种方案缺点也比较明显，如果大家都在主干进行开发，当代码提交合并时，将会异常痛苦，一不小心就会出现冲突。而且，这种因为这种方式没有明显的特性分支，想要移除已经上线的特性会变得非常困难。（如果你说把不要的功能注释，重新发版，那就当我什么也没说。）还有一种方案是引入特性开关，通过开关控制特性是否启用和关闭，但是增加开关就引入了复杂性，引入复杂性就引入了出 bug 的风险，毕竟多增加的每行代码都有可能是一个新的 bug。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"heading","attrs":{"align":null,"level":2},"content":[{"type":"text","text":"GitFlow"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"GitFlow 来源于 Vincent Driessen 提出的 "},{"type":"link","attrs":{"href":"https://nvie.com/posts/a-successful-git-branching-model/","title":""},"content":[{"type":"text","text":"A successful Git branching model"}]},{"type":"text","text":"，整体来说，是一套完善的版本管理流程。缺点就是太过严格，不太适合喜欢自由而且懒的程序猿。当然，在程序猿这种物种中，没有完美的解决方案，总有那么一小撮人会觉得不好。参考 Ant、Maven 和 Gradle。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"先上图："}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"image","attrs":{"src":"https://static001.geekbang.org/infoq/f3/f3ecc3cf5b3902dbb1ff2356fe65e67e.png","alt":"GitFlow：A successful Git branching model","title":null,"style":null,"href":null,"fromPaste":true,"pastePass":true}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"GitFlow 常用分支："}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"bulletedlist","content":[{"type":"listitem","content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"主干分支（"},{"type":"codeinline","content":[{"type":"text","text":"master"}]},{"type":"text","text":"）：最近发布到生产环境代码的分支，这个分支只能从其他分支合并，不能再 Master 分支直接修改。"}]}]},{"type":"listitem","content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"主开发分支（"},{"type":"codeinline","content":[{"type":"text","text":"develop"}]},{"type":"text","text":"）：包含所有要发布到下一个 Release 版本的代码。可以在 Develop 直接开发，也可以将 Feature 的特性代码合并到 Develop 中。"}]}]}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":" "}]},{"type":"image","attrs":{"src":"https://static001.geekbang.org/infoq/f5/f5d4d66820a5b77ad7bc363a3503b28e.png","alt":"主开发分支","title":null,"style":null,"href":null,"fromPaste":true,"pastePass":true}},{"type":"bulletedlist","content":[{"type":"listitem","content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"特性分支（"},{"type":"codeinline","content":[{"type":"text","text":"feature/*"}]},{"type":"text","text":"）：功能项开发分支，以"},{"type":"codeinline","content":[{"type":"text","text":"feature/"}]},{"type":"text","text":"开头命名分支，当功能项开发完成，将被合并到主开发分支进入下一个 Release，合并完分支后一般会删掉这个特性分支。"}]}]}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":" "}]},{"type":"image","attrs":{"src":"https://static001.geekbang.org/infoq/4d/4dc8ef862b4e1e70fc45f6d00773160b.png","alt":"特性分支","title":null,"style":null,"href":null,"fromPaste":true,"pastePass":true}},{"type":"bulletedlist","content":[{"type":"listitem","content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"发布分支（"},{"type":"codeinline","content":[{"type":"text","text":"release/*"}]},{"type":"text","text":"）：基于主开发分支创建的一个发布分支，以"},{"type":"codeinline","content":[{"type":"text","text":"release/"}]},{"type":"text","text":"开头命名分支，用于测试、bug 修复及上线。完成后，合并到主干分支和主开发分支，同时在主干分支上打个 Tag 记住 Release 版本号，然后可以删除发布分支。"}]}]}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":" "}]},{"type":"image","attrs":{"src":"https://static001.geekbang.org/infoq/ae/aeb5cb758836d84cbbd9b319a462825a.png","alt":"发布分支","title":null,"style":null,"href":null,"fromPaste":true,"pastePass":true}},{"type":"bulletedlist","content":[{"type":"listitem","content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"热修复分支（"},{"type":"codeinline","content":[{"type":"text","text":"hotfix/*"}]},{"type":"text","text":"）：用于解决线上 Release 版本出现的 bug，以"},{"type":"codeinline","content":[{"type":"text","text":"hotfix/"}]},{"type":"text","text":"开头命名分支，修复线上问题，完成后，合并到主干分支和主开发分支，同时在主干分支上打个 tag。"}]}]}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":" "}]},{"type":"image","attrs":{"src":"https://static001.geekbang.org/infoq/fa/fa159868df4a416d391c6fd832851f9a.png","alt":"热修复分支","title":null,"style":null,"href":null,"fromPaste":true,"pastePass":true}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"根据上面描述，GitFlow 是一套完整的从开发到生产的管理方式，但是各种分支来回切换及合并，很容易把人搞晕，所以用的人也是越来越少。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"heading","attrs":{"align":null,"level":2},"content":[{"type":"text","text":"AoneFlow"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"AoneFlow 是阿里内部的一套版本管理模型，兼顾了 TrunkBased 易于持续集成和 GitFlow 易于管理需求的特点，又规避了 GitFlow 分支繁琐的缺点，也就是中庸。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"AoneFlow 使用三个分支：主干分支（"},{"type":"codeinline","content":[{"type":"text","text":"master"}]},{"type":"text","text":"）、特性分支（"},{"type":"codeinline","content":[{"type":"text","text":"feature/*"}]},{"type":"text","text":"）、发布分支（"},{"type":"codeinline","content":[{"type":"text","text":"release/*"}]},{"type":"text","text":"），以及三条原则："}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"规则一，开始工作前，从主干分支创建特性分支。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"这条规则借鉴了 GitFlow，每当开始一件新的工作项（比如新的功能或是待解决的问题，可以是一个人完成，或是多个人协作完成）时，从代表最新已发布版本的主干分支上创建一个通常以"},{"type":"codeinline","content":[{"type":"text","text":"feature/"}]},{"type":"text","text":"前缀命名的特性分支，然后在这个分支上提交代码修改。也就是说，每个工作项对应一个特性分支，所有的修改都不允许直接提交到主干。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"image","attrs":{"src":"https://static001.geekbang.org/infoq/9f/9f2440f805c5ff703410547b646d4dc2.jpeg","alt":"从主干创建特性分支","title":null,"style":null,"href":null,"fromPaste":true,"pastePass":true}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"特性分支不止承担了新功能，也是待解决问题的分支。对于我们团队，为了避免歧义，会将新功能以"},{"type":"codeinline","content":[{"type":"text","text":"feature/"}]},{"type":"text","text":"为前缀，待解决问题以"},{"type":"codeinline","content":[{"type":"text","text":"hotfix/"}]},{"type":"text","text":"为前缀，除了名称外，其他都按照规则一执行。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"规则二，通过合并特性分支，形成发布分支。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"GitFlow 先将已经完成的特性分支合并回主干分支和主开发分支，然后在主干分支上打 Tag 记录发布信息。TrunkBased 是等所有需要的特性都在主干分支上开发完成，然后从主干分支的特定位置拉出发布分支。而 AoneFlow 的思路是，从主干上拉出一条新分支，将所有本次要集成或发布的特性分支依次合并过去，从而得到发布分支，发布分支通常以"},{"type":"codeinline","content":[{"type":"text","text":"release/"}]},{"type":"text","text":"前缀命名。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"image","attrs":{"src":"https://static001.geekbang.org/infoq/85/85f2947ab195a3554689e89693e8987c.jpeg","alt":"合并特性分支，形成发布分支","title":null,"style":null,"href":null,"fromPaste":true,"pastePass":true}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"我们可以将每条发布分支与具体的环境相对应，"},{"type":"codeinline","content":[{"type":"text","text":"release/test"}]},{"type":"text","text":"对应部署测试环境，"},{"type":"codeinline","content":[{"type":"text","text":"release/prod"}]},{"type":"text","text":"对应线上正式环境等，并与流水线工具相结合，串联各个环境上的代码质量扫描和自动化测试关卡，将产出的部署包直接发布到相应环境上。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"另外，发布分支的特性组成是动态的，调整起来特别容易。在一些市场瞬息万变的互联网企业，以及采用“敏捷运作”的乙方企业经常会遇到这种情况，已经完成就等待上线的需求，随时可能由于市场策略调整或者甲方的一个临时决定，其中某个功能忽然要求延迟发布或者干脆不要了。再或者是某个特性在上线前发现存在严重的开发问题，需要排除。按往常的做法，这时候就要来手工“剔代码”了，将已经合并到开发分支或者主干分支的相关提交一个个剔除出去，做过的同学都知道很麻烦。在 AoneFlow 模式下，重建发布分支，只需要将原本的发布分支删掉，从主干拉出新的同名发布分支，再把需要保留的各特性分支合并过来就搞定，而且代码是干净的，没有包含不必要的特性。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"此外，发布分支之间是松耦合的，这样就可以有多个集成环境分别进行不同的特性组合的集成测试，也能方便的管理各个特性进入到不同环境上部署的时机。松耦合并不代表没有相关性，由于测试环境、集成环境、预发布环境、灰度环境和线上正式环境等发布流程通常是顺序进行的，在流程上可以要求只有通过前一环境验证的特性，才能传递到下一个环境做部署，形成漏斗形的特性发布流。当然，这种玩法比较适合有完整开发集成平台的公司，小团队玩不转，比如我们团队就玩不动这种高级玩法。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"规则三，发布到线上正式环境后，合并相应的发布分支到主干，在主干添加 Tag，同时删除该发布分支关联的特性分支。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"当一条发布分支上的流水线完成了一次线上正式环境的部署，就意味着相应的功能真正的发布了，此时应该将这条发布分支合并到主干。为了避免在代码仓库里堆积大量历史上的特性分支，还应该清理掉已经上线部分特性分支。与 GitFlow 相似，主干分支上的最新版本始终与线上版本一致，如果要回溯历史版本，只需在主干分支上找到相应的版本标签即可。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"image","attrs":{"src":"https://static001.geekbang.org/infoq/26/264f42057b170d56ed0c30ed9ad8f318.jpeg","alt":"合并相应的发布分支到主干，在主干添加 Tag，同时删除该发布分支关联的特性分支","title":null,"style":null,"href":null,"fromPaste":true,"pastePass":true}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"除了基本规则，还有一些实际操作中不成文的技巧。比如上线后的热修复，正常的处理方法应该是，创建一条新的发布分支，对应线上环境（相当于 Hotfix 分支），同时为这个分支创建临时流水线，以保障必要的发布前检查和冒烟测试能够自动执行。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"heading","attrs":{"align":null,"level":2},"content":[{"type":"text","text":"再啰嗦几句废话"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"不管哪种方式，既然存在，都会有一定合理性。所以，不管最终翻了哪个牌子，不是因为这个好看，而是因为这个更适合自己。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"image","attrs":{"src":"https://static001.geekbang.org/infoq/9e/9e305acd1cca75053c144cb28adc6061.png","alt":"公众号：看山的小屋","title":null,"style":null,"href":null,"fromPaste":true,"pastePass":true}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}}]}