前端项目git管理规范

一、 规范要求

1、 每个项目建立单独的git库，必须写README文件，描述项目整体。

2、新仓库只有master主分支和dev开发分支，并且 主分支和开发分支都应受保护，开发人员不允许直接在上面进行开发，只有项目管理者才能操作；

3、 协同开发时，先将远程库克隆到本地，然后基于dev分支创建自己的开发分支，功能开发完成后推送到远程库；

4、 提交分支时注明：项目+动作类型（新增、修改、删除）+改动明细；

5、 版本号命名规则：xx.xx.xx (大版本.功能性扩展.bug修改)

6、 禁止把无关文件上传到git库，如：密钥、视频等。仅上传代码；

7、 每天上班前拉取一次远程代码，下班前至少提交一次代码；

二、分支规范

主分支 　　

1、master ：随时可供在生产环境中部署的代码 　　

2、dev： 保存当前稳定并且最新的开发分支

辅助分支

副主分支主要用于新功能的并行开发、对生产代码的缺陷进行紧急修复工作等，合并 master后应该立即删除，使得仓库的常设分支只有master和dev。

1、功能分支feature

用于开发新功能时所使用的feature分支，从dev分支上面分出来的。开发完成后，再合并到dev分支，最后删除feature_*分支。

2、预发布分支release

用于发布正式版本前(合并到master前)的 release分支，当dev分支已经实现了产品需求的所有功能后，从dev分支上面分出来的，主要用于最后测试，测试完成后合并到dev和master分支，合并到master分支后，做一个标签，如v1.1.0，最后删除release_*分支

3、修补bug分支bug

用于修正生产代码中的缺陷的bug分支，从master分支上面分出来的，修复结束后再合并到dev和master分支，合并到master分支后，做一个标签，如v1.1.1，最后删除bug_*分支

4、辅助分支命名规则：分支类型_开发者_时间_开发模块  

feature分支:feature_yourname_20190506_moduleName

bug分支：bug_yourname_20190506_moduleName

release分支：release_yourname_20190506_moduleName

三、commit 日志规范

git提交尽量遵循单次提交的代码是对一个完整但是影响劲量小的修改，不要把对几个功能的修改一起提交，提交信息一定要认真填写！

参考ng的commitizen

格式 projectName：type description

type是commit的类型：

fix：修复 xxx bug

add：新增 xxx 功能

update：更新 xxx 功能

style：修改 xxx 样式文件

docs：变更 xxx 文档

test：增加测试

revert：使用revert撤销上一次的commit

reset：使用reset撤销上一次的commit

四、合并规范

1、在feature分支上开发时，如果dev分支有变动，比如别人的功能开发完成并上线，需要将完成的功能合并到自己的分支上，即合并dev到当前feature分支。

2、当进行一个release分支时，若dev分支有变动，如其他开发人员完成功能并上线 , 则需要将完成的功能合并到自己分支上，即合并develop到当前release分支

3、合并到dev分支上的代码必须是完整可运行的，不能影响其他人。

4、master分支只接受release分支和bug分支进行合并。

5、合并到master分支的代码必须经过严格测试封板后才能合并，并且打上对应的tag标签v1.0.0，参照版本号命名规则。

切换分支 git checkout master

合并分支 git merge dev

查看所有tag git tag

查看tag详情 git show v1.0.0

新增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 push --tags

删除本地tag git tag -d v1.0.0

删除远程tag git push origin --delete v1.0.0