前端常用规范
开发规范
无规矩不成方圆，无规范难以协同， 规范的目的是为了编写高质量的代码。对软件来说，适当的规范和标准绝不是消灭代码内容的创造性、优雅性，而是限制过度个性化，以一种普遍认可的统一方式一起做事，提升协作效率，降低沟通成本。
命名规范
项目命名
- 全部采用小写方式， 以中划线分隔。
正例：mall-management-system
反例：mall_management-system / mallManagementSystem
目录命名
- 采用中划线分隔，有复数结构时，要采用复数命名法， 缩写不用复数
正例： scripts / styles / components / images / utils / layouts / demo-styles / demo-scripts / img / doc
反例： script / style / demo_scripts / demoStyles / imgs / docs
文件命名
- 采用中划线分隔
canvas-props.vue
变量或方法命名
- 变量名采用小驼峰式(Camel)命名
- 方法名采用小驼峰式(Camel)命名，注意动作语义化前缀 can | has | is | get | set ｜ add | edit | del
- 事件以 on / un/ handle 前缀
- 常量采用全大写+下划线
const UNIT_TEST = 'test' - 类名采用大驼峰式命名
class Home extends Vue{ }
样式规范
- 组件内样式必须通过 scpoe 控制作用范围
- 样式类名采用中划线连接
class="test-ele" - id 采用小驼峰式命名
id="testIdName" - scss 中的变量、函数、混合 采用驼峰式命名
Git规范
分支模型
- master 分支表示一个稳定的发布版本，在 preview 分支测试稳定后, 会合并到 master 分支, 并使用 tag 标记应用版本，tag 规范: v{APP_version}, 例如 v0.1.0
- dev 分支，开发者主要工作的分支, 最新的特性或 bug 修复都会提交到这个分支，开发者如果在该分支进行了提交，在 push 到远程之前应该先使用 rebase 模式 pull 一下，保证分支的简洁，在 dev 分支中也可能会经历发布过程, 例如 bug 修复版本. 这里同样使用 tag 来标记这些发布. 例如 v0.1.1
- feature 分支，涉及多人协作或者大功能的开发, 应该从 dev 分支 checkout 出独立的 feature 分支, 避免干扰 dev 分支，命名：feature.name，name 是功能名称
- preview 分支，预发布分支，临时合并 dev / feature 分支，用于支持测试环境
- release 分支，从 master 切出 release 分支用于发布，命名：release.{GZB_version}，用于支持生产环境
提交信息规范
- feat: 引入新功能
- fix: 修复了 bug
- docs: 文档
- style: 优化项目结构或者代码格式
- test: 增加测试