git规范看起来很简单,但如果执行不好的话,十分容易出问题,比如丢代码、出线上bug
仓库位置
前端业务代码,只能创建在前端群组的git仓库中,不允许建在个人名下,不允许创建在其余的地方
权限分配
前端业务代码,owner必须为前端负责人,不接受后端owner负责
不允许创建任何内部员工都有权限的公用代码,群组外人员权限需要手动赋予
git提交权限已经很敏感,再加上与之挂钩的上线权限,所以授予外部人员权限,采用权限最小化
策略,够用即可
分支管理
个人经历不同的公司,有不同的管理方式,但都有共同的特点
- 有稳定上线分支、有持续开发分支
- 按feature/时间_业务功能_开发人员方式创建个人开发分支,如
feature/20220524_xxxList_zhangsan
- 如果需要fix线上问题,可以随时基于线上的稳定分支打出hotfix分支出来,便于及时上线
代码提交信息
git commit
杜绝无意义的提交,方便追踪代码
提交格式:type (scope): message
scope:本次提交代码影响的业务模块,可选
type | 描述 |
---|---|
feat | 新功能的开发 |
fix | bug的修复 |
docs | 文档格式的改动 |
style | 代码格式改变 |
refactor | 对已有的功能进行重构 |
perf | 性能优化 |
test | 增加测试 |
build | 改变了build工具 |
revert | 撤销上一次的commit提交 |
chore | 构建过程或辅助工具的变动 |
代码提交频率
按模块完成程度提交,如果当天完成了3个模块,那就在每个模块完成之后提交当前模块
禁止一下子提交若干功能不相干的代码模块
严禁一整天/N天不提代码,可以拆分子功能点,阶段性提交代码
git commit 信息细化
接上一个,当做一个比较大的模块的时候,例如需要三天完成,也是需要每天至少提交一次代码的
不允许每次提交的信息均为 feat:xxx模块
,这样也不利于代码追踪
有两种提交建议
前端开发50%、前端开发完成、接口联调30%、接口联调80%、接口联调100%
……如此的步骤+百分比的信息提交方式- 按
大模块-子模块
信息提交
代码提交校验
如果当前系统开启了eslint校验,也需要同时开启git提交时的校验,保证代码提交的质量
angular提交规范
目前业内最著名的提交规范,是angular的提交规范,相比较上述提交内容,多了提交的body、footer信息
个人在团队共创的时候,聊起过这个规范,团队小伙伴一致觉得略麻烦,遂放弃
这是因为我们一直做业务开发,如果是做对外组件库开发的话,就需要采取一下这个规范了
重要模块review机制
即使个人有权限直接推到master,如果核心代码改动的比较大,建议至少另外一位核心开发同事来review本次改动
欢迎查阅本专栏其余前端相关规范
-
html css js 三驾马车 3篇
前端规范 - html规范
前端规范 - css规范
前端规范 - js开发规范 -
开发框架类 1篇
前端规范 - vue开发规范 -
开发实践类 5篇
前端规范 - git使用规范
前端规范 - 前端注释规范
前端规范 - 前端广义安全规范
前端规范 - 前后端接口规范
前端规范 - 前端项目开发规范