开发规范
保证开发代码的统一性，方便各前端开发的阅读和维护。
重点：项目开发中必须对关键功能实现代码添加注释（注意，注意，注意）
1. 前端目录构建规范
我们从命名原则、根目录、业务逻辑等方面进行目录构建
1.1 命名原则：- 简洁明了（如下：）
- src 源代码
- img 图片资源
- js JavaScript脚本
1.2 根目录（root）结构按职能划分（如下：）
- src 源代码（逻辑）
- doc 文档
- dep 第三方依赖包
- test 测试
1.3 根据业务逻辑进行文件夹的划分（如下：）
- src目录名词解释：
- common 公共资源
- public/static 静态资源
- component 组件
- view/tpl 模板文件
1.4 总结：以上目录开发规范有两种使用途径
- 使用前端工程化工具如webpack、gulp等进行手动打造
- 利用框架提供的脚手架工具进行修改
现公司项目开发可参考上列命名文件
2. 前端命名规范
1.项目中所有命名均由英文命名（如无英文能准确翻译时，可使用同义单词）。
2.命名由多个单词组成时使用驼峰式命名如：userName(用户名称)或 ‘‘ 分割，如：username。
3.vue项目组件名应按官方推荐的kebab-case 如：my-component-name或PascalCase（首字母大写）如：MyComponentName
3.代码管理git
git大致用法
公司项目主要分支：
master:项目主分支（线上分支），除项目管理者外其余人员不可提交修改该分支内容。
urgencyBug:紧急BUG处理反正。从master（线上）拉取，处理完后交于测试。测试OK，合并到master上线。上线完 urgencyBug必须及时删除
dev:开发版本主分支（测试主分支），项目迭代，推进的代码存放处，项目开发者可拉取该分支获取最新代码。
当多个开发人员同时开发，各负责几个功能，可各自命名自己的私人分支，同时告诉该项目主要推进人，由负责人来合并开发人员的各自分支到dev。
测试：1.先将dev分支打包成测试包，交于测试人员，测试无bug后合并至master打包，再次交于测试人员打包，测试无误 方可上线。
git clone -b dev-ztt git地址
git status (看看修改的文件)
git add ./file (将需要提交的提交到暂存区)
git commit - m ‘feat: 注释’ （提交到本地）
git push (提交到远程)
git pull origin master (从远程拉分支)
git规范
git add 时候不允许 git add . 这样很容易把一些不必要的文件给提交上去了
git commit 规范 feat：新功能（feature） fix：修补 bug docs：文档（documentation） style： 格式（不影响代码运行的变动） refactor：重构（即不是新增功能，也不是修改 bug 的代码变动） test：增加测试 chore：构建过程或辅助工具的变动
git push 时候不允许 直接提交主分支 这样可能会污染主分支
git管理者
代码审查（这样可以避免一些危险的代码）
规范审查（git 提交规范、代码书写规范）为以后维护的人员打好基础
开发人员定期代码相互审查（发现问题、相互学习、万一有开发人员有假期，其他人员可以快速接受他的活）
控制好版本
