提到分支管理我想大家脑子里闪现出来的一定是GIT对不对!(你要是SVN可就暴漏年龄了)
Git用法就不必多说了,你百度下一大堆,这里给大家分享下自己管理团队分支时的方法,欢迎补充~
1 固定分支开发(本地环境,测试环境,生产环境)
假设项目初步建立完成,此时只有一个分支master,然后公司老板说,我们有钱了,给你再搞台服务器专门做测试用!
那么这时你将分支从master上切出来了两个,test分支,dev分支。
你告诉大家,以后我们发生产环境只能用master发布!发测试环境只能用test发布! 自己在自己的dev分支上开发需求!
如果需求很多,自己本地要针对每一个需求单独开个分支,比如:dev_imageBug, dev_itemNum,dev_log;
你可以将三个分支都合并到test上面,测试通过的功能,再合并到master上发生产。
2 版本迭代
一开始你用固定分支开发遇到了一个问题!
有一次明明测试通过的一个功能,和到了master上除了bug,这时产品对测试发了一通牢骚,测试对开发发了一通牢骚,开发对自己发了一通牢骚。
固定分支的弊端暴露了出来——虽然功能分支(比如:dev_imageBug)合并到测试分支没有问题,但是测试的时候测得时test分支,而不是dev_imageBug分支。
用dev_imageBug分支合并到master发布生产环境,这样的方法可以说是,把没有经过测试的分支(dev_imageBug)直接合并到了要发布生产环境的分支上了,危险,危险!
因此团队成员头脑风暴了一番(emmm,我当时是问了其他团队学来的)后决定采用一种船新的模式。
现在开始,我们切一个新的分支出来!叫做 feature_v1 !我们这周要上线5个功能! A B C D E F ! 这5个功能写好,并到feature_v1 上面发测试,
测试通过之后,周四直接用feature_v1发布线上,没问题后,将feature_v1的代码合并到master上面!
而且此时我们要再切出来一个分支叫feature_v2 ! 这个分支是用来下一周功能的开发的!循环往复直到开发到feature_v9999我们就此生圆满了
perfact! 测试的分支就是发布生产环境的分支,这样就避免了将没有经过测试的分支发到了线上!
如果此时有bug需要可以在线上分支切出来一个feature_hotFix分支进行修复,应为bug不属于第二周的版本迭代。