上个月公司来了位前端大佬,给我们团队制订了一些技术方面的规范,其中有一项是关于在 Git 上提交代码写 Commit Message 的一些规范。开始我还觉得多此一举,看了许多大型项目的 Commit 记录之后,才知道这个规范算是行业里的标准。
先来看看我的 CodeStudy
项目里是写的什么 Commit Message:
再看看尤雨溪大佬的作品 Vue 框架的 Commit Message:
果然一个规范的 Commit Message 真的能让人眼前一亮,可以快速了解到该 Commit 的内容和涉及的功能模块。下面说说规范化 Commit Message 能带来什么好处。
规范化的好处
- 便于程序员对提交历史进行追溯,了解发生了什么情况。
- 一旦约束了
Commit Message
,意味着我们将慎重的进行每一次提交,不能再一股脑的把各种各样的改动都放在一个git commit
里面,这样一来整个代码改动的历史也将更加清晰。 - 格式化的
Commit Message
才可以用于自动化输出Change log
。
Git 提交规范
text 代码:<type>(<scope>): <subject>
<body>
<footer>
名称 | 作用 |
---|---|
type | 用于说明 Git Commit 的类别,只允许使用下表的标识 |
scope | 用于说明 Commit 影响的范围,比如数据层、控制层、视图层等 |
subject | Commit 目的的简短描述,一般不超过 50 个字符 |
body | 可忽略,可多行,详细的描述,与 header 之间空一行 |
footer | 可忽略,一般用于不兼容更新或关闭 issue,与 body 之间空一行 |
类型 | 描述 |
---|---|
sync | 同步主线或分支的 bug |
merge | 代码合并 |
revert | 回滚到上一个版本 |
chore | 构建过程或辅助工具的变动 |
test | 增加软件测试 |
perf | 优化相关,比如提升性能、体验 |
refactor | 重构,既不是新增功能,也不是修改 bug 的代码变动 |
style | 格式,不影响代码运行的变动 |
docs | 文档撰写或更新 |
fix / to | 修复 bug,可以是 QA 发现的 bug,也可以是研发自己发现的 bug |
feat | 新功能(feature) |
插件推荐
在 VS Code 上面强烈推荐 Commit Message Editor
插件,可以快速生成 Git Commit Message。
此内容仅评论者及博主可见