研发规范
研发人员须知,重要!!
项目编码规范
规定项目中锁遵守的编码规范和风格
使用 ESLint 进行编码规范的约束
必要的规则合计
在项目中必须使用以下两种规则合集:
'extends': [
'plugin:vue/essential',
'eslint:recommended',
],
这两个规则集合整好约束了项目对应的两种语言类型:Vue2 文件编码、JS 通用编码规范
规则详情
如果想了解规则的详情,可以参看如下的连接:
推荐插件
请使用 vscode 并且安装 eslint、vetur 插件,在编辑器内获取显示错误的能力
推荐的其他规则
按照个人或者团队的医院,可以选择一些扩充的 js 规范作为补充。
Airbnb Javascript 编码规范(Github 103k星)
Airbnb ESLint 合集:https://www.npmjs.com/package/eslint-config-airbnb
规则详情:https://github.com/airbnb/javascript#types
关于 Prettier 的使用
使用 Prettier 对代码进行格式化,但是可能会和 ESLint 有冲突,所以需要进行一些设置才能一起进行良好的工作。
项目文件结构规范
项目文件结构和命名规范如下:
/assets (静态文件)
common
logo.png
...
...
/components (所有组件, 使用 Pascal 命名方式)
ColorPicker
index.vue
Dropdown
index.vue
...
/views (所有路由, 使用 Pascal 命名方式)
Home
index.vue
...
/router (路由配置文件)
index.js
...
/store (全局 store 配置文件)
models
editor.js
user.js
...
index.js
getters.js
...
/utils (公共方法)
index.js
...
/layout (布局)
index.js
Header
index.vue
Sidebar
index.vue
...
/mixin
common-table-list-mixin.js
...
/test (测试文件)
ColorPicker.spec.js (使用Pascal命名方式,和组件名称相同,以 spec.ts 结尾)
App.vue
main.js
...
Git Flow 规范
规范采用固定双分支 master and dev
master 作为主分支
dev 作为开发分支
创建分支
开发新功能或者修复 bug 之前,要用最新的 dev 分支代码,拉新的分支,然后进行开发。git 分支命名规范如下:
master
主干分支,当前正在运行的代码。不可直接往master
提交代码。dev
开发分支,当前正在开发、但尚未发布的代码。不可直接往dev
提交代码,但可以合并其他分支。server
开发分支,用于部署 server 端功能,不可直接往server
提交代码,但可以合并其他分支。feature-xxx
开发新功能fix-xxx
bug 修复hotfix-xxx
高优紧急 bug 修复,修复完需紧急上线doc-xxx
仅修改文档,不修改代码
提交 commit
请按照一下步骤提交代码,不要怕麻烦
git status
确认修改的文件,都符合预期git diff
确认修改的内容,都符合预期git add .
git commit -m "xxx"
提交代码,此时会自动进行 eslint 和 prettier 的检查和修复,请耐心等待
注意,在执行 git commit
时,请务必遵守 commit 规范,程序也会强制按照如下格式提交:
feat: xxx
新功能 —— 【注意】请务必谨慎使用feat
,除非真的是新功能,否则不要乱用。fix: xxx
bug 修复style: xxx
修改样式docs: xxx
修改文档refactor: xxx
重构某个功能test: xxx
增加或修改测试用例chore: xxx
修改辅助功能(如 webpack eslint 等)perf: xxx
性能优化release: xxx
发布新版本revert: xxx
回退
例如,你本次 commit 是修复了一个 bug ,那就执行 git commit -m "fix: 说明本次修改了哪个 bug"
Commit 信息,杜绝 update,fix bug 这类废话,每次提交必须言之有物,至少要言简意赅的把一次 commit 完成的任务说清楚。
创建 PR(Pull Request)
创建 Pull Request ,将当前分支合并到 dev 分支(不是 master 分支),重要!!
然后,一定要自己先看一看 PR 的 Files Changed ,看是否符合自己的预期,重要!!如果不符合预期,则把这个 PR 关掉,再重新修改代码,重新提交 PR 。
代码 review 过后即可 merge
重要!!