– 关注前端和node js,分享福利和心得!

前端项目git管理规范

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



最新文章

    热门文章