团队规范之Git规范

        在实际开发中，无论是 Git 版本的规范，还是 Git Commit 的规范，都是一环较重要的部分，因为他们绝对是大有裨益的；

• 方便跟踪工程历史；

• 方便快速回溯代码；

• 方便 Code Review；

• 方便生成 CHANGELOG；

• 提高项目的整体质量，提高个人工程素质；

1、Git 版本规范 

版本规范其实有许多种工作流形式，有 Git flow，有集中式工作流，有功能分支工作流；

这里主要说一下较为常用的 功能分支流；

功能分支工作流是以集中式工作流为基础的。它提倡为各个新功能分配一个专门的分支来开发， 当功能分支稳定，或者说经过完备的测试之后才合并到 master 分支。

功能分支工作流相较集中式工作流的优点：

• 保持主干的干净。隔离了多个开发者在各自功能上的开发不会扰乱主干代码

• 提供了Code Review的空间。功能分支在合并到主干之前，触发集成测试，或者开启Pull Request, 启动一个围绕分支的讨论。发挥群众的力量。

2、Git Commit 规范

<type>(<scope>): <subject>
// 注意冒号 : 后有空格
// 如 feat(user): 增加用户中心的 xx 功能

• feat：新功能 feature

• bug：测试反馈 bug 列表中的 bug 号

• fix： 修复 bug

• ui：更新UI；

• docs： 文档注释变更

• style： 代码格式(不影响代码运行的变动)；

• refactor： 重构、优化(既不增加新功能，也不是修复bug)；

• perf： 性能优化；

• release：发布；

• deploy：部署；

• test： 增加测试

• chore： 构建过程或辅助工具的变动

• revert： 回退

• build： 打包

• scope 表示 commit 的作用范围，如用户中心、购物车中心，也可以是目录名称，一般可以限定几种；

• subject 用于对 commit 进行简短的描述；

• type 必填，表示提交类型，值一般有以下几种：

• 统一格式：

结合工具强制使用 Git Commit 规范：

• 使用 commitlint 、commitizen 和 husky 来进行提交检查；

• 使用 commitlint-config-cz 规范命令行提示消息（可选）；

• 使用 conventional-changelog 提交日志。

---

新时代农民工