前端规范 - git使用规范

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模块，这样也不利于代码追踪
有两种提交建议

1. 前端开发50%、前端开发完成、接口联调30%、接口联调80%、接口联调100%……如此的步骤+百分比的信息提交方式
2. 按大模块-子模块信息提交

代码提交校验

如果当前系统开启了eslint校验，也需要同时开启git提交时的校验，保证代码提交的质量

angular提交规范

目前业内最著名的提交规范，是angular的提交规范，相比较上述提交内容，多了提交的body、footer信息
个人在团队共创的时候，聊起过这个规范，团队小伙伴一致觉得略麻烦，遂放弃
这是因为我们一直做业务开发，如果是做对外组件库开发的话，就需要采取一下这个规范了

重要模块review机制

即使个人有权限直接推到master，如果核心代码改动的比较大，建议至少另外一位核心开发同事来review本次改动

欢迎查阅本专栏其余前端相关规范

• html css js 三驾马车 3篇
  前端规范 - html规范
  前端规范 - css规范
  前端规范 - js开发规范

• 开发框架类 1篇
  前端规范 - vue开发规范

• 开发实践类 5篇
  前端规范 - git使用规范
  前端规范 - 前端注释规范
  前端规范 - 前端广义安全规范
  前端规范 - 前后端接口规范
  前端规范 - 前端项目开发规范