学习
实践
活动
专区
工具
TVP
写文章

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

关于分支

工作中几个项目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分支搞定。

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

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

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

  • 发表于:
  • 原文链接http://kuaibao.qq.com/s/20180318G0UZQN00?refer=cp_1026
  • 腾讯「腾讯云开发者社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

关注

腾讯云开发者公众号
10元无门槛代金券
洞察腾讯核心技术
剖析业界实践案例
腾讯云开发者公众号二维码

扫码关注腾讯云开发者

领取腾讯云代金券