git企业级版本管理
一、介绍
git大家都知道，是一个开源的分布式版本控制系统，用于敏捷高效地处理任何或小或大的项目。它和SVN最大的不同，在与git分支的遍历。
但往往企业在使用git时，也仅仅把git当做SVN来使用，并没有很好的利用起git的分支，每个人都提交一堆commit，建立一堆杂乱无章的分支，导致项目的管理混乱。
所以需要企业根据实际的开发需要，定义一个git版本规范，是很有必要的。
二、分支命名
- 分支线
- master：主分支，始终与线上发布的版本保持一致，只做合并，不做提交
- test：测试分支，对应测试环境的分支
- dev：开发分支，对应开发环境的分支
- hotfix：火速修复分支，当线上代码出现bug，基于master分支创建出一个新的分支，进行修复bug
- 命名规则：[分支线]_[年月日 ]_信息
- 如开发权限代码：dev_20211128_auth
- 如线上支付出现bug：hotfix_20211128_pay
三、开发发布流程
3.1）正常版本需求开发
- 当开发人员需要开发新需求，开发人员需要基于master创建出一个新分支，注意分支名称要规范，例如
dev_20211128_auth - 开发人员需要将分支拉取到本地开发，只拉取刚刚创建的
dev_20211128_auth- 如果是组内共同开发的同个功能，同样拉取一样的分支
- 开发人员完成开发后，上传代码远程分支至远程分支
- 根据自己业务开发需要，决定自己提交至远程的代码，例如一天一次提交等
- 全部完成后，远程分支
dev_20211128_auth拥有了你们所有功能代码，此时合并至dev分支 - 然后将dev分支打包构建只开发环境
- 当自测通过，将
dev_20211128_auth合并至test分支- 不能将
dev合到test分支，因为dev上可能有其他小组还在联调的代码
- 不能将
- 测试通过时，可以上线的情况下，将
dev_20211128_auth合并至master分支，然后进行打包构建发布
3.2）线上问题紧急修复
- 线上有bug，需要修复时，基于master创建出一个hotfix分支，例如
hotfix_20211128_pay - 开发人员拉取分支进行修复
- 开发修复完成后，将
hotfix_20211128_pay合并至dev进行联调或者自测 - 当自测通过，将
hotfix_20211128_pay合并至test分支 - 测试通过时，可以上线的情况下，将
hotfix_20211128_pay合并至master分支，然后进行打包构建发布
3.3）dev、test分支测试有bug反馈
- 当dev、test分支有bug反馈，需要在本地进行修复bug时
- 不能直接修改dev、test分支，应当从自己开发功能的分支上进行修改bug
- 修改完成后，再将自己的开发功能分支合并到dev、test分支上，重新进行测试
四、分支清理
- 当每个版本上线后，自己的功能开发分支都将删除
- 每隔一段时间，dev、test分支都将删除，重新基于master创建
- 主要是避免代码污染，某些人没有按照规范，直接提交到dev、test分支了
- 最好在没有功能需求的空窗期进行
五、结语
上述就是git代码的管理，以前确实很乱，有了规范分支也清楚。
每个企业，开发的资源环境不同，比如有些没有统一的开发服务器，比如有的还有预发布环境。可以根据企业自身，进行适当的修改，但规范一定是要有的，本文仅供参考。
git大全
git命令小游戏
