git管理规范 ​

一、 规范要求 ​

1. 每个项目建立单独的git库，必须写README文件，描述项目整体。
2. 新仓库只有master主分支和dev开发分支，并且主分支和开发分支都应受保护，开发人员不允许直接在上面进行开发，只有项目管理者才能操作；
3. 协同开发时，先将远程库克隆到本地，然后基于master分支创建自己的开发分支，功能开发完成后推送到远程库；
4. 每次push推送前必须先拉取最新的远程代码，发现冲突，需要找对应同事沟通合并代码
5. 提交代码时注明：项目+动作类型（新增、修改、删除）+改动明细；
6. 版本号命名规则：xx.xx.xx (大版本.功能性扩展.bug修改)
7. 禁止把无关文件上传到git库，如：密钥、视频等。仅上传代码；
8. 每天上班前拉取一次远程代码，下班前至少提交一次代码；

二、分支规范 ​

主分支 ​

1. master ：随时可供在生产环境中部署的代码
2. dev： 保存当前稳定并且最新的开发分支

辅助分支 ​

辅助分支主要用于新功能的开发、对生产环境代码进行bug修复工作等。

1. 按功能模块划分的分支 用于开发新功能时所使用的分支，从master分支上面拉取。开发完成并测试通过后，再合并到master分支。
2. 修补bug分支bug 用于修复生产环境中的紧急bug分支，从master分支上面拉取，修复结束后再合并到功能分支和master分支，合并到master分支后，做一个标签，如v1.1.1，最后删除bug_*分支

辅助分支命名规则 ​

feature分支:moduleName_date bug分支：bug_date

三、工作流 ​

首先，我们根据体量给项目做一个区分，聚合系统和单系统。 聚合系统：类似于运营系统或者总管理后台那样，涉及到多个系统的，我们称之为聚合系统。(每增加一个单系统，一般在聚合系统里都有对应的功能模块体现)

单系统：单独拆分出来的子系统或者新建的功能相对单一的系统我们称之为单系统。

对于聚合系统，从主分支master拉取一个功能分支，以模块(子系统)和日期命名，如orderModule_20200101，日常都在对应的模块分支上开发，该分支下的功能全部开发完成后，以该分支进行提测，如果测试出现bug，直接在该分支上进行修复，测试通过后，再合并到master分支 ，将master分支发布uat环境测试。

对于单系统，仓库初始化时会基于主分支master创建dev开发分支，开发人员直接拉取dev到本地，在dev分支上进行开发即可(其实就相当于聚合系统中固定名字的功能分支)，dev分支下的功能全部开发完成后，以dev分支进行提测，如果测试出现bug，直接在dev分支上进行修复，测试通过后，再合并到master分支 ，master分支发布uat环境测试。

四、commit 日志规范 ​

git提交尽量遵循单次提交的代码是对一个完整但是影响尽量小的修改，不要把对几个功能的修改一起提交，提交信息一定要认真填写！ 参考ng的commitizen 格式 projectName(聚合系统可以写项目名称，单系统可写功能点)：type(类型) description(描述) type是commit的类型：

五、合并规范 ​

1. 在模块分支上开发或者test环境测试时，如果master分支有变动，比如别人的功能开发完成并上线，需要将完成的功能合并到自己的分支上。
2. 在进行uat环境测试时，如果发现bug，需要在对应的功能分支上修改，并合并到master分支
3. 合并到master分支的代码必须经过严格测试封板后才能合并，并且打上对应的tag标签v1.0.0，参照版本号命名规则。

切换分支	git checkout master
合并分支	git merge dev
查看所有tag	git tag
新增tag   git tag -a v1.0.0 -m "新增v1.0.0版本"
切换到某个tag	git checkout v1.0.0
提交单个tag	git push origin	v1.0.0
删除本地tag	git tag -d v1.0.0
删除远程tag	git push origin --delete v1.0.0