git相关规约

1. 提交规约

简单采用<type>(<scope>): <description>的方式进行规范，如：feat(packsges/map):新增map组件，其中：

type

type 是 commit 的类别，只允许如下几种标识：

• fix: 修复bug
• add: 新功能
• update: 更新
• style : 代码格式改变
• test: 增加测试代码
• revert: 撤销上一次的commit
• build: 构建工具或构建过程等的变动，如：gulp 换成了 webpack，webpack 升级等
• docs：文档（documentation）
• perf：优化相关，比如提升性能、体验。
• merge：代码合并

scope

scope` 用于说明 commit 影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同。

description

description 是对本次提交的简短描述，建议使用中文。不超过50个字符。

2. Git 分支命名规约

2.1 分支模型选择的说明

目前互联网和社区中流传最广泛的一个分支模型 Git Flow 出自 a-successful-git-branching-model 这篇十年前的文章，文章作者 Vincent Driessen 在 2020 年三月份的时候已经公开表示，该分支模型已经不适用于现如今持续交付的软件工程方式，推荐在持续交付的软件工程中使用更简单的 Github Flow 模型。

2.2 分支命名

新建分支的命名格式为：{type}-{issue id}-the-thing-you-do

• type：和上文 1.3.1 章节中的 type 保持一致
• issue id：与分支内容相关的 issue id，如果无关，则可以忽略

比如以下格式都满足规范：

• feat-ssr-prefetch：新增 ssr prefetch 功能
• fix-1379-component-insert-order：修复 issue 1379 中提到的组件插入顺序 bug
• revert-14218-memory-leak-on-unmount：回退版本解决 issue 14218 提到的组件卸载时内存泄露的问题

注：该命名规约只针对新建的临时分支，不包括如 master、develop 等常驻分支

2.3 多版本分支命名

在需要同时维护多个版本的项目中，只使用 master 作为主干分支显然是无法满足需求的，但是又不想使用 Git Flow 这种复杂、繁琐的分支结构，那么就可以每发布一个新的版本就单独拉一个新的分支，例如：

• 1.0.0-stable
• 2.0.0-stable

其他开发过程中的分支命名参考上节 2.2 的分支命名规约。

3. Git tag 命名规约

Git tag 就是通过语义化的名称来给仓库标注一个个具体的节点。与此同时还可以根据标签名称来大致了解当前项目的兼容性和迭代情况。

命名格式为 v{semver}，semver 是遵循 semantic version 的版本号，例如 v1.2.3。

相比于使用例如 git tag v1.2.3 这种「轻量标签」，更推荐使用如下命令生成「附注标签」：

git tag -a v1.2.3 -m "发布经销商管理模块"