引言

CI/CD是DevOps 的基础核心，做好CI/CD是保证能够频繁向客户交付应用的基础。其中CI指的是持续集成，即频繁地（一天多次）将代码集成到主干。CD指的是持续交付，旨在以更高的速度和频率构建、测试和发布软件。CI要有效率，但是，现阶段软件规模越来越庞大，成百上千的开发人员在同一代码库上协作提交代码，通常会出现代码越多质量越差的情况，如何保证持续稳定的发布版本，不让代码提交成为项目瓶颈？今天我们来聊一聊为了做好CI，如何进行代码的分支管理？

软件开发经过多年的发展，开发模式经过不断的演进，同时代码管理工具也在不断的更新换代，眼下最流行的代码版本管理系统，非Git莫属了，相比同类软件，Git的一个很显著的优点，就是具有优秀的分支模型 , 创建/合并分支非常的方便，它能支持多人协同开发同时，保证版本清晰的演进。

Git分支管理策略（GitFlow）

1.1常设分支

常设分支指的是指日常开发工作中始终存在的分支，包括master分支和develop分支。

1.1.1master-主干分支：

每个代码仓库有且只有一个master分支，master分支是用于发布到生产环境的分支，代码时刻处于生产就绪状态。为保证产品版本稳定，必须进行严格的管理控制，比如不允许在master分支上直接修改代码，只允许从其他分支合入；在发布准备期，只接受修复bug，不接受新功能代码合入等等。

1.1.2 Develop-开发分支：

由于master分支只发布重大版本，不允许直接修改代码，日常开发都在develop分支上完成，如果想正式发布，就需要在Master分支上，对Develop分支进行"合并"（merge）。

1.2 临时分支

前面讲了master和develop两个常设分支，其实这两条已经可以满足一般开发场景的需求了，但是，为了应对一些特定目的的版本开发，还需要一些临时性分支，临时性分支在开发完合入到其他分支后一般都会删除掉，需要的时候再临时创建。

1.2.1 feature-功能分支：

如果团队规模比较大，数十上百个开发人员都不断的向develop分支提交代码，难免会引入诸多问题，所以在需要开发一个新的功能特性时，会从develop上拉取一个feature分支，在这个分支上进行功能特性的开发，开发完成经过验证没有问题，再合入develop分支。

1.2.2 release-预发布分支：

在发布正式版本之前，我们需要对即将发布的版本进行测试，bug修复，这时可以从develop分支上拉取一个release分支，在这个分支上进行测试和bug修复，预发布结束后必须将这个分支合并进develop和master分支。

1.2.3 hotfix-修补bug分支：

版本正式发布后，难免会出现bug，这时需要在master分支上拉取一个hotfixes分支，在此分支上进行bug修复后，再合入master和develop分支上。

写在最后的话

以上介绍了git分支管理策略，做好CI跟很多因素有关，工具可以一定程度上帮助团队解决一些问题，但是工具不是万能的，还需要依赖具体的人、流程、规范、开发模式等等因素。团队在开发运作中与工具、流程不断磨合找到最适合自己团队的方式才是最重要的。