基于git工具的代码管理方案

基于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的时候需要将对应版本提交上去，开发关闭的时候会回复对应解决包的版本。或者时间。