开发中使用多分支还是单分支

关于分支

工作中几个项目GIT分支的使用方式都不同，各有特色，这里简化了一下，拿两个具有普遍性的例子出来对比。

使用多个分支进行开发，分支对应环境

一般流程

从develop分支上checkout，建立各自的feature分支进行开发。

功能开发好了，从feature分支合并到develop分支。

develop分支确认发布的功能集合，合并到uat分支

uat测试通过，上升到master分支进行生产发布

一般的开发流程为：各自feature -> develop -> uat -> master

备注

develop分支对应 DEV环境

uat分支对应 UAT环境

master分支对应 PRD环境 (生产)

这样的开发方式在前期比较爽，可以在自己的feature分支上尽情狂奔。

问题

合并是多分支的一个最大的问题。在一个活跃的项目上，在新分支上奔跑了半个小时，合并起来估计毫无压力；但如果是狂奔了半个月，估计合并的时候想死的心都有了，那种感觉就好像20几年后回老家，发现以前的班花变成大妈了一样。另外在没有自动化测试或单元测试保护下，合并是一件高危工作，因为一不小心看错几个字，很有可能在合并的时候引入bug。

如果在一家庞大的机构工作，还有可能面临多团队的代码合并问题，这样成本又是另外一个量级。

多分支的话，在合并前你需要保证自己的变更不会炸掉一个工作良好的代码库，你需要一个独立的测试环境，这样，多分支隐性带来了多测试环境。如果没有多测试环境的话，恭喜你，瓶颈落到了测试环境上。如果有测试环境的话，也恭喜你，你要维护多套测试环境。

使用单一分支进行开发，用版本号部署环境

前面说了那么多关于多分支的坏话，我们来看看单分支开发。

一般流程

所有人有master上进行开发

新的功能需要先建立一个功能开关，在功能没有通过测试前，开关默认为关闭状态

每天多次部署master到测试环境，测试通过手动打开功能开关进行测试

当功能通过测试后，提交代码，更改功能开关默认为打开

每次提交代码都生成一个版本

选取合适版本部署到 DEV/UAT/PRD 环境

一般的开发流程为：建立开关 -> 在master上开发 -> 测试通过 -> 打开开关 -> 确认某个版本上 uat -> uat 版本通过后上生产

好处

好处显而易见的，通过开关做功能性的“隔离”

大家的代码可以很早就集成到一起，使问题可以很快浮到水面，真正做到快速的集成。

问题

好了，分支是没有了，测试环境也可以变为一个，一切看上去都很美好。事实上，出来混，迟早都是要还的。开关方式用久了以后，稍不小心就会有以下的代码：

估计也没谁想去维护这么一堆东西。这个方法要求开发者不要写多层的开关嵌套，要定期清理，最好需要专人监管，并且需要有强大的自动化测试来保证开关的状态和行为一致。最后，你可能需要写一个代码扫描工具，一旦开关已经开启超过某个时间而依然存在，就让build失败，来减少这种代码的污染。

小结

使用单个分支或多个分支，这个各有好处，不可以一概而论。我们也可以在上面策略的基础上做一些改进，例如多分支开发的同时，合并后手动发布版本号，利用版本号部署到DEV/UAT/PRD环境。具体还是要看团队的水平和规模，代码库的活跃程度来决定。

例如代码库不太活跃，可以只用一个master分支搞定。

如果不同的开发人员较多，改的代码没太多重合的地方，多分支也挺好。

万一好几个人改同一个地方，我建议最需要做的不是吵着决定用什么分支方法，而是几个人坐在一起，统一意见决定怎么改，最好是手把手，好基友结对编程。

无论单分支还是多分支，根本要解决的是多人在同一代码库上工作的问题。该沟通的时刻，工具是帮不了太多忙的。