Git 使用规范：起名字、提交描述的最佳实践
1. 推荐写法（本人常用）
Git 仓库命令规则：
- 前端：系统名-简单描述-front
- 后端：系统名-简单描述-server
Git 提交描述：
docs(changelog): update change log to beta.5其中：
● docs 则对应修改的类型
● changelog 则是影响的范围
● subject 则是对应做的事件
对应的类型有：
- build：影响构建系统或外部依赖关系的更改（示例范围：gulp，broccoli，npm）
- ci：更改我们的持续集成文件和脚本（示例范围：Travis，Circle，BrowserStack，SauceLabs）
- docs：仅文档更改
- feat：一个新功能
- fix：修复错误
- perf：改进性能的代码更改
- refactor：代码更改，既不修复错误也不添加功能
- style：不影响代码含义的变化（空白，格式化，缺少分号等）
- test：添加缺失测试或更正现有测试
2. 工作写法
Git 提交描述：
一般公司会使用一些第三方工具，例如：Jira、Ones等，通过这些看板工具来管理团队的任务。每一个任务都会有对应的任务号。
因此，这个时候提交就会规范一点：
# 类似格式 如下：
[任务卡号] xx & xx: do something # 举个例子，Ones格式如下：
#79612 描述内容
http://ones.xxx.com/project/#/team/HvBrmPic/task/GSCnZc5zd2dDgl8F
3. 常规写法
[任务分类] 主要修改组件（可选）：修改内容
示例 1，[T] tabs: add icons 。其中的 T 表示这是一个技术卡，tabs 表示修改的是 Tabs，add icons 则表示添加了图标。
示例 2，[SkillTree] detail: add link data。其中的 SkillTree 表示修改的是技能树 Tab 下的内容，detail 则表示修改的是详情页，add link data 则表示是添加了技能的数据
优点：轻松 filter 出相应业务的内容。
缺点：要这样做需要团队达到一致，因此付出一些额外的成本。
💡以上参考：GitHub 漫游指南