命名规范

目录

由于 Windows 和 OSX下对文件大小写不敏感，因此我们采用kebab-case命名法。

基础用法

例如：项目文件夹 my-project-name

复数

项目内的子文件夹按照作用，采用常规单词命名。不使用缩写，除非已经约定俗成的惯用法。

例如：脚本文件 scripts、模块modules、 组件components

文件

和目录一致，采用kebab-case

变量

采用camelCase，且使用英文名词

✔️ 正确示例：userCount 、listItems

❌ 错误用法：setCount set 是动词

常量

采用UPPER_CASE，即全部使用大写字母，多音节用 _ 分割例如：MAX_COUNT、URI

函数

采用camelCase，前缀为动词

例如：getName 建议的动词约定

类**&**构造函数

采用PascalCase

类的成员包含 2 部分

1. 公共属性和方法：跟变量和函数的命名一样。
2. 私有属性和方法：前缀为_(下划线)，后面跟公共属性和方法一样的命名方式。

URL及路由

大小写不敏感，因此采用kebab-case

例如：mobile/design-tools

编码风格及样式规范

• 文件编码: 使用utf-8

• 缩进符: 使用空格代替 Tab

• 缩进位: 使用2个空格

• 换行符: LF

• 文件尾: 新增一个空白行

· 尾部空格: 行尾无空格安装 VS code 的 editor 插件

• 进入 VS code 左侧第五个菜单(最后一个)，顶部搜索中输入editorconfig
• 在列表中选择 EditorConfig for VS Code进行安装
• 重启 vs code 在使用 VS code 时，VS code 会自动读取项目下的 .editorconfig 文件，并应用到你的编码里

配置好之后，按一下，如果自动缩进了 2 个空格，说明配置成功

标准 .editorconfig 内容为

root = true [*] charset = utf-8 indent_style = space indent_size = 2 end_of_line = lf insert_final_newline = true trim_trailing_whitespace = true

其余风格使用 ESlint Standard

项目workflow

Git分支

合并原则

所有的$Feature只允许单向合并到develop，不允许$Feature互相合并，只允许develop单向合并到master分支。

基础流程

1. 建立 issue

当我们想要实现一个功能时，不要急于立即开始写代码。先想清楚大概要实现什么目标?评估一下会怎么去实现?最基础的设计是什么?把这些都写到一个 issue 里。issue 标题可遵循动词+名词的形式，如实现页面无限滚动

2. 创建分支和 Merge Request

手动新建一个自己的分支，并将该分支 checkout 到本地。

在 issue 建立之后，当你的权限是develop时，你会发现gitlab提供一个便捷选项——在 issue的右下方，叫做Create a merge request，点击之后(不要点下拉菜单)，会同时帮你创建一个以issue名称命名的分支，也同时创建了一个Merge request，此时这个Merge

request尚未被执行，处于WIP(working in progress)的状态。这个时候把新创建的分支

Check Out到本地，开始你的开发之旅。

3. 合并入 Develop

经过一段时间的开发，你的开发完成了，并且也已经通过了自测。这个时候就需要把你的开发工作合并到Develop分支上去了。完成提交和推送后，回到你原来的 issue，你会发现可以直接进入之前创建好的Merge request,进入之后先解除WIP状态，然后进行Merge。如果顺利的话，你的代码将会被合并入Develop分支

4. 合并入 Master

在 develop 分支已经积累了一部分功能，需要对外发布时，则创建一个新的Merge request，将develop分支合并入master,这一步是不需要任何其他代码提交的。

变基而非反向合并

在实际工作中，我们有时会遇到在自己开发分支上开发的时候，发现develop比自己的分支要新，为了保持自己的分支也是在最新的基础上开发，我们想当然的会想把develop合并入自己的分支。但这样的结果就会出现交叉合并，对于日后分析项目和理解项目是非常不利的。

因此我们采用变基Rebase操作，将我自己的分支Rebase到develop最新的节点上即可。

Git Commit Message 规范

1. 目的

• 统一团队的 Git commit 日志标准，便于后续代码 review，以及自动化生成 Changlog 等
• 养成良好的写作习惯和对自己作品负责的态度

${type}(${scope}): ${subject}
//blank line
${body}
//blank line
${footer}

2. 基本规范

type****类型

type 代表某次提交的类型，比如是修复一个 bug 还是增加一个新的 feature。

格式要求

标题行：50个字符以内，描述主要变更内容

主体内容：更详细的说明文本，建议72个字符以内。需要描述的信息包括：

• 为什么这个变更是必须的? 它可能是用来修复一个bug，增加一个feature，提升性能、可靠性、稳定性等等

• 他如何解决这个问题? 具体描述解决问题的步骤

• 是否存在副作用、风险?

尾部：如果需要的化可以添加一个链接到issue地址或者其它文档，或者关闭某个issue。

3. 例子

新增了一个组件时：

feat(component): created LocaleProvider component for locales inject //blank line
- add inject methods to pagination, calendar
- add provider methods to locale-provider
//blank line close #23

参考资料

angular

ivweb

Commit message 和 Change log 编写指南