Git是一个开源的分布式版本控制系统，可以有效、高速的处理从很小到非常大的项目版本管理。非常适合做互联网产品的代码版本管理。
如何使用git进行版本管理，并解决产品开发过程中的提出来的版本控制的问题，就是我要表达的意思。
团队如何进行版本管理呢？
第一，GitServer的选型和安装
我选用了GitLab作为GitServer。GitLab是一个开源的版本管理系统，实现一个自托管的Git项目仓库，可通过Web界面进行访问公开的或者私人项目。它拥有与Github类似的功能，能够浏览源代码，管理缺陷和注释等，还有一个功能，它能够实现分支的在线合并申请，分支可以进行保护等权限的控制。
第二，版本号定义规范
约定版本号规范，每个模块的版本号约定为三位<main>.<feature>.<hotfix>，根据大的基线设定<main>主要版本号，根据当前版本设定<feature>次版本号，<hotfix>默认为0，当有bug修改后才更新这个版本号。每次产品人员定义好产品功能后，每次变更<feature>版本号即可。
第三，创建固定分支
每创建一个项目，分别创建dev、test、release、master四个固定分支。
dev分支用来研发人员进行自测和模块间联调使用的，用来部署到研发环境的，开发人员对该分支有pull和push权限。
test分支是测试人员进行测试的代码分支，是部署到测试环境的代码分支，研发人员联调完自测完成后，提交feature分支合并申请到test分支，由管理员负责代码review并进行代码合并，该分支是受保护分支，开发人员对该分支有pull权限。
release分支是在test分支测试完成后，由研发人员提交test分支合并申请到release分支，release代码分支是用来部署到预生产环境的，由管理员进行代码合并。
master分支是最终上线的代码分支，测试人员在预生产环境测试通过后，由研发人员提交release代码分支合并申请到master分支，master分支是要部署到生产环境的，master上线完成后打对应版本的tag标签。
第四，临时分支
feature分支，每次定义产品一个完整的基线版本就生成一个feature_{版本号}分支，上线完成后删除该分支，所有的人创建一个属于自己的分支，每个人自测完成后，发起自己分支合并到feature分支，然后将feature分支合并到dev分支。
hotfix分支，每次bug修复创建一个hotfix_{版本号}分支，生产环境出现bug后，需要马上修改时，确定好版本号，从继承master分支创建hotfix分支。
第五，正常上线流程
1）管理员创建固定的分支dev、test、release和master版本，根据产品人员确定的功能确定当前版本的版本号，并继承master分支创建feature分支。
2）每个研发人员拉取feature分支，并创建个人本地分支。
3）研发人员进行编码，自测完成后合并本地分支合并到feature分支，并将feature分支合并到dev分支部署到研发环境进行模块间联调。
4）研发人员联调通过以后，向管理员发起feature分支合并到test分支的申请，由管理员review代码后完成合并，并部署到测试环境。
5）测试人员在测试环境进行测试，发现bug并登记，由研发人员进行修改，重新从第3步开始重复执行。
6）测试人员测试通过以后，由研发人员发起从test分支向release分支合并申请，由管理员完成合并，并部署到预生产环境。
7）测试人员测试预生产环境测试通过后，由研发人员发起从release分支向master分支的合并申请，有管理员完成合并，并在master分支上打版本标签，并部署到生产环境。
8）测试人员验证生产环境通过后，上线完成，如果生产环境验证不通过，马上回滚到master上一次的版本代码。
第五，线上从来不缺bug，如何处理线上紧急Bug呢？
1）研发人员从继承master分支创建一个hotfix分支。
2）研发人员检出hotfix分支，自测通过后提交并申请分支合并到release分支，由管理审核通过后完成合并，并部署到预生产环境。
3）由测试人员对预生产环境进行测试，测试通过后，由研发人员发起从release分支合并到master分支的申请，由管理员审核通过后完成合并，并在master分支上打版本标签，并部署到生产环境。
4）测试人员验证生产环境通过后，上线完成，如果生产环境验证不通过，马上回滚到master上一次的版本代码。
转载自网络 不用于商业宣传 版权归原作者所有，侵权删。
