前端项目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