【干货分享】大话团队的GIT分支策略进化史

 


封面

作为一名85后的技术男,一转眼10年过去了(一不小心暴露了年龄,虽然我叫18岁fantasy),亲手写代码已经是5年前了,目前主要负责公司的软件产品的规划和设计(所以最近写的东西也主要与设计和产品分析有关)并带着研发团队进行产品落地。偶尔手痒痒写点代码或者和团队讨论一下架构设计啥的,毕竟以前是那么的热爱!

这篇文章主要想写写我所在团队git的使用历程,有些算是回忆吧。~老司机共勉啊~

SVN时代

在刚进公司的时候,那会大家都还在使用svn。代码,原型设计和过程文档都在svn上。大概过了一年,整合svn大小40个G(大概两个千万级项目的代码和文档),每次更新要人命,也给实施团队和方案团队带来了很多困惑,后来就直接把研发从svn上分出来了,但还是svn管理,svn只用来做内部文档管理。

那个时候主要面对项目开发,团队也比较集中,都在北京,项目的特征就是一次性交付,后面有部分变更开发和bug修改。所以从分支上来说基本上就是这样的。


单项目svn

大家都在主分支上开发,然后定时提交,到了上线节点QA把代码checkout下来开始测试。测试完后把bug清单发给研发,研发一顿改,之后提交,QA再回归测试,基本上没问题然后就上线了。

暴露问题:

随着时间的发展,大家有不少时间花在解决冲突上,因为其他人提交了有bug的代码(团队有要求必须自测后提交但,但是自测能力参差不齐),有时候量大了能折腾一上午,基本上最后提交之前都得先本地备份一下,生怕应为冲突而代码丢失了。

引入GIT

随着业务的扩展和团队的发展,北京,武汉,长春都有了研发基地,这种扯皮的事情更多了,并且由于网络的不稳定,很多时候代码提交都出现了问题,通过内部沟通研究,决定将代码管理从svn迁移到公网码云(gitee)上,当时也研究了github之类的。最好考虑还是用了国内的,毕竟还有社区啥的,平时吐个槽看个科技前言新闻也方便。

上了git之后,一开始也只解决了地域问题,大家可以在各自的城市畅通无阻的提交代码了,同时团队也加强了代码审核和自测培训。但是基本上没有分支的概念,那个时候,GIT的使用是这样的。


gitc之初

此阶段解决的问题:

分布式团队,分布式提交。

产生的问题:由于团队要求每天代码必须提交到远程。但是自测结果任然具有不确定,bug还是满天飞,每天一来还是要处理冲突。

引入分支

通过团队讨论,代码每天下班远程提交是必须的,为了防止影响别人,就引入个人分支(团队任务基本上按人按模块分工,前后端不分离),于是就给了每个人或者开发同一个模块的几个人建一个分支(如果同一个分支几个人之间有小矛盾内部自己解决吧),那个时候起名一般按照“项目名_模块名”起名,比如:dxplat_logmgr(下文暂时用git的专用名称feature代替)。每天写完代码,如果还没完成就先提交,然后确定测试完之后再合并到主分支。


引入分支

解决的问题:

可按地域分布式提交。

可远程提交到自己的分支,不影响主分支。

产生的问题:

项目上线后,一个项目实施(简称A)完之后,另外一个相同业务的项目(B)也中标了,但是需求还不尽相同。并且A项目在质保期,还得修修改改,添添补补。怎么能同时满足这两个项目并发升级上线呢。如果按照以前的方法,就是管你A和B,我就是一个工程,然后最后都是打一个包给你(说到这很多人应该有同感),同时包含A+B。实施人员你去部署吧,上线配置小心点改,A项目改A的参数,B项目改B的参数。

随着时间的推移,同业务域定制的项目越来越多,这样下去不是办法,由于上线时间不一致,主分支都不敢随便提交了,QA正在测试A项目的时候B项目也催的着急,也得提交代码让另外一个AQ测试啊。而且代码也慢慢失控了,改起来别提多费劲了,各种依赖包整的项目臃肿的不行不行的了。

引入release分支

团队讨论之后,决定引入release分支,一个项目上线后,通过master建立release分支用来支撑不同需求的项目,定时选择性的将不同项目里面的模块合并到master,开发人员都基于release做开发,并且这个release会一直保留,因为用户永远都有小心思。同时新的项目来了之后都从mater再创建release去应付新的定制需求。整个开发流程变成下面的情况:


release

至此这个策略用了至少2年,一直坚持在用。并且对待项目型的开发总体感觉用着还行,网上有人说少了dev分支,团队内部讨论整体感觉对项目型没必要再搞个dev分支,因为项目基本上是瀑布式开发直到上线,中间迭代上先次数基本很少,要上线也是所有需求满足直接上先。但是最后还是用上了。

接着往下发展~

终于公司部分业务产品化了,也面向公众和企业用户了。需求也多了,面对竞争对手也必须快准狠的面对市场了。

总结产品和项目不同的特征如下:

1、项目具有固定周期,项目结项完毕,开发工作也基本结束了,后期修修补补。产品当然也有周期,但是不是客户定的周期,而是企业战略和市场决定。

2、项目基本瀑布式开发,而产品如果竞争激烈,那就必须敏捷迭代,对需求池进行排序,快速跟进。

3、产品和项目都具有可复制特性。但是项目的复制由于客户需求的不同,需求范围有很大的不同,也就是所说的定制化程度高,基本上是方案和设计思想的复制,其他都是大量定制开发。而产品一旦确定用户群和需求痛点这些大方向,基本上是一个线性开发的过程。不断开发迎合市场和企业战略的新需求,废弃没必要和过时的老需求。

云端产品和终端产品的区别:

如果云端产品,那个所有用户都会感知一个版本。而如果是终端产品的话,不同的终端用户群会有不同的产品版本,根据公司策略和客户要求去升级。

那么对于产品化的分支策略,开发需不停的在完成需求池中需求的开发。市场则需根据市场策略上线不同的版本,比如有的功能是技术公关,作为公司与竞争对手的pk点,就不能过于超前上线,以便被抄袭。有的是用户最关心就必须在竞争对手之前上线。

这个时候以前的分支策略问题就来了。必须有一个分支是时刻能上线的代码,而且能记录不同的版本(有的版本上线后有bug,需要修改,但是用户也不需要新功能)。

引入TAG

通过在mater上记录tag来记录每次上市的产品版本,如果这个版本有bug,但是用户当前不需要新的需求,就直接在这个tag上创建临时的分支给用户改bug,改完之后代码将代码合并到master。这个时候我们一般不删除这个临时分支,因为鬼知道后面还有啥bug呢,有点类似于release分支,但是和release不同的是,这个只用来改bug,新的功能开发都必须在mater上。开发流程就变成了这样:


产品化分支策略

这里面的问题就是QA测试的时候master不能合并新的代码只能改bug。一旦合并新的功能,上线范围就变了,就得重新测试。必须测试完打上tag之后才行。但是有时候公司内部须对全功能进行内部演示和访谈调研,就必须有一个全版本的分钟,而mater作为发布版本,又能随便合并。怎么办呢,就是引入dev分支。

引入DEV分支

具体做法就是创建dev分支,版本上线是,合并到mater,QA从mater上pull代码做测试用于测试上线,有bug建分支改,改完bug,master和dev上都合并。但是这个时候dev上开发的新模块不合并到mater,大家提交还是往dev上提交,内部演示都从dev打包做演示。下次上线依然是提交到mater让QA测试(这一块和网上很多人说的不一样,大家都是从dev上做测试,然后没问题合并到mater)。这样下来分支就变成这样:


dev分支

有些地方会和网上的会有差别,比如我们是在最后才引入dev分支的。

总结

1、针对项目和产品我们采用了两套策略,项目用release策略,产品用tag策略。

2、另外如果是集中式开发的小团队小项目,只基于mater开发也不是不可,也挺灵活,加上严格的代码审核和自检培训就行了。

3、这里面基本也用到GIT的三种工作流的思想(Git Flow,GitHub Flow,GitLab Flow),加入了自己的一些实践和定制。

关于pull request

对于git中的pull request协作机制,实际应用中也基本没用上,感觉比较适合外包或者开源协作项目(多个不太熟悉的小团队合作开发一个项目)。如果是内部团队,毕竟这种协同机制内部定死也没必要线上处理了。

我们的代码审核时间有时候不在上线前,基本上会周五或者周一由专人进行(一方面审核代码及完善审核规则,一方面培训新人),而并不是提交一个模块就让人审核,这样如果功能点太多,审核人的时间就很零碎。但是上线的功能肯定是审核过了的,而且会有严格的代码测试。


零零碎碎也了很多,欢迎大家一起讨论吧,有问题也欢迎留言提出。

总之,适合自己团队和公司的就是最好的,用发展的眼光看待技术。

posted @ 2019-06-04 13:00 crazy_joe 阅读(...) 评论(...) 编辑 收藏