基于git工具的代码管理方案
git是一个十分简单的工具,里面有各种复杂的功能。但是针对每个团队,又有着必须要的功能,和一些不必要的功能。为此我结合我们公司团队的规模,和项目模块划分,人力等因素设计了一套简单实用的git管理源代码的方案
方案需求
- 应对线上包,能及时处理相关用户反馈和bug修复。
- 开发各个版本可以同时进行,减少相互之间的影响。
- 代码回溯,bug追踪等基本功能。
- 针对现在存在模块耦合性大,合并的效率,需求作用域等问题的优化
关键词
在实际设计的简洁方案中,主要使用到git的这些关键分支和功能解释
- Master分支:主分支,
- Release分支:测试版本分支,
- Develop分支:开发分支
- 各自的开发分支:
- submodule的使用:子模块
首先是代码管理方案
使用上面的所用的分支,下面介绍每个分支的在实际使用中的作用,和我们开发的具体操作流程。
- Master分支:要保护它的稳定性,随时可用来上线;不在 master 分支上直接提交代码,而是合并其余分支;具有代码存储的功能。(由一个人管理)
- Release分支:只会有微小改动,通常也是线上的发布分支,待发布线上验证通过后,Release分支才会合并master,Release分支是master的版本快照。(由一个人管理,修改频率要保证一天一次的合并,并且与下面包的Release分支最好是一一对应的)
- Develop分支:所有的开发都是将自己的代码合并到这个上面,并且要保证自己合并上去的代码能编译通过,然后各自处理相关,都在本地合并,然后编译成功后再提交到服务器上。(都可以修改)
- 各自的开发分支:需要实时的合并服务器上的Develop,只保存到本地,自己测试通过后,合并到Develop中,生成一个功能程序。
- submodule的使用:在我们的开发中,有两个地方需要用到这个东西,一个是图片识别,和视频处理的底层dll和lib,不在使用之前的共享去获取了。而是使用git中自带的submodule来,提示所有的开发人员进行替换对应的 头文件和lib。并且备注修改内容
包的管理方案
使用到分支Master分支,Release分支
Master分支保存每个在线包的情况,在一些特殊情况下得时候,需要对某个包做特殊处理的时候再建立单独的版本分支。这分支上最为重要的是tag的标识,为了方便快速的找到对应发出去的包。
Release分支:测试分支只要在测试稳定一个版本后,签名后合并进Master分支中。普通测试,或者验证问题的时候不在使用安装包的方式进行安装了(除非是测试安装流程的时候,或者与安装相关的东西的时候,我们才会打安装包了),测试人员也从git中获取最先的程序来进行测试。这样才可以加快测试的流程,并且快速查看修改日志,所以在提交release分支的时候,要尽量详细的描述修改程序对软件影响并且备注相关修改问题。
新测试流程
上诉已经提到,就是我们的测试流程不在是传统的给安装包的形式了,而是直接从git上直接拉去最新的整个程序进行测试。及时反馈问题到jira,提交bug的时候需要将对应版本提交上去,开发关闭的时候会回复对应解决包的版本。或者时间。