Git使用——commit规范

一、制定目的

1. 统一团队Git commit日志标准，便于代码review，版本发布以及日志自动化生成等。
2. 统一团队的Git工作流，包括分支使用、tag规范、issue等

二、Git工作流

1. 分支规范

分支类型	命名规范	创建自	合并到	说明
master	master	–	–	长期分支，部署到生产环境中的代码
develop	develop	–	master	长期分支，进行代码集成的分支
feature	feature/*	develop	develop	短期分支，新功能分支
release	release/*	develop	develop和master	短期分支，一次新版本的发布
hotfix	hotfix/*	master	develop 和 master	短期分支，生产环境中发现的紧急 bug 的修复，唯一可以直接从master分支fork出来的分支

• 三个短期分支类型一旦完成开发，它们就会被合并进develop或master，然后被删除。

• 分支的名称应该遵循一定的命名规范，以方便开发人员识别。

• 当需要开发一个新的功能时，基本的流程如下：

从 develop 分支创建一个新的 feature 分支，如 feature/my-xxx。
在该 feature 分支上进行开发，提交代码。
当代码提交完成之后，push feature分支到远端仓库。
在gitlab上创建合并请求

三、Commit规范

1. 概述

一个commit 应该包括一个准确的逻辑改动。一个逻辑改动包括增加新的特性或修改特定的Bug，如果不能在较高层次用简短语句描述这个改动，就说明它对于单个commit 来说太复杂了，应该拆分它！把你的代码改动拆分为多个 commit。

• 以下习惯，有则改之，无则加冕：

总是在每天下班前commit今天所有的改动，这种commit不会清晰。
懒汉式的commit信息，如“修改了几个Bug”，这种信息毫无意义。
两个改动放在一次 commit 中。如“修改用户注册不成功的处理和用户登录的验证”，请把它拆开分别 commit。
有些动词用现在时，而不是完成时，例如不要说“改好了(fixed)…，解决了(solved)…, 增加了(added)…，修改了(revised)…”，而应该说“增加(add)…，修改(revise)…，解决(solve)…”
在git commit 上增加 -m 或 --message= 参数进行提交，提倡使用git commit或可视化的提交

1. Git commit日志基本格式

():<@taskid> 

1. 格式说明

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

• feat： 新增feature
• fix: 修复bug
• docs: 仅仅修改了文档，比如README, CHANGELOG, CONTRIBUTE等等
• style: 仅仅修改了空格、格式缩进、都好等等，不改变代码逻辑
• refactor: 代码重构，没有加新功能或者修复bug
• perf: 优化相关，比如提升性能、体验
• test: 测试用例，包括单元测试、集成测试等
• chore: 改变构建流程、或者增加依赖库、工具等
• revert: 回滚到上一个版本

1. 格式要求

• 标题行：50个字符以内，描述主要变更内容
• 主体内容：更详细的说明文本，建议72个字符以内。 需要描述的信息包括:
• 为什么这个变更是必须的?

它可能是用来修复一个bug，增加一个feature，提升性能、可靠性、稳定性等等
他如何解决这个问题? 具体描述解决问题的步骤
是否存在副作用、风险?
修复BUG时，关联BUG编号

• 示例：

feat(用户): @TaskID，新增登录注册功能

 # 新增系统登录登录功能，可使用邮箱、密码进行用户注册；
 # 邮箱发送验证码，验证通过后，即可登录。