代码仓库-分支策略
采用合适的分支策略，可以最大限度的减少构建各个环境代码包能遇到的问题。在一个项目的各个阶段，可以采用不同的分支策略，减少CI/CD可能遇到问题
Git分支策略
1. TrunkBased
工作方式
TrunkBased （Trunk based Development）模式是持续集成思想所崇尚的工作方式，它由单个主干分支和许多发布分支组成，每个发布分支在特定版本的提交点上从主干创建出来，用来进行上线部署和 Hotfix（补丁）。
由于开人员之间通过约定向被指定为主干的分支提交代码，因此避免分支合并的困扰，保证随时拥有可发布的版本 。“主干”这个词隐喻了树木生长的场景，树木最粗最长的部位是主干，分支从主干分离出来但是长度有限。
缺点
它的缺点比较明显，太多的团队同时工作在主干上，到发布的时候就可能出现灾难（尤其是多版本并行开发的情况）。
弥补措施
弥补的措施是 FeatureToggle（特性切换） 以及频繁的集成和足够的测试覆盖。
使用场景
目前 TrunkBased 模式主要用在不需要同时维护多个历史版本的 SaaS 型项目，特别是经过微服务改造的各种小型服务上。
2. GitFlow
工作方式
GitFlow 模式是若干模式的集大成者，包含一个主干分支、一个开发分支、许多的特性分支、许多的发布分支和 Hotfix 分支，以及许多繁琐的合并规则。
缺点
但它使用起来并不是很容易，大量的合并冲突和对集成测试不友好也是它被诟病最多的地方。
与TrunkBased的异同
在 TrunkBased 的基础上，增加了个人仓库和 Pull Request 合并代码的操作，与在同一个仓库里增加个人分支的做法类似。GithubFlow 也有演进版本，例如强调了多环境部署和将仓库或分支与环境关联的 GitlabFlow 模式。
使用场景
从实用的意义来说，它更合适分布式团队。
4. AoneFlow
AoneFlow 使用三种分支类型：主干分支、特性分支、发布分支，以及三条基本规则。
规则一，开始工作前，从主干创建特性分支。
规则二，通过合并特性分支，形成发布分支。
规则三，发布到线上正式环境后，合并相应的发布分支到主干，在主干添加标签，同时删除该发布分支关联的特性分支。