「这是我参与2022首次更文挑战的第15天，活动详情查看：2022首次更文挑战」
Hope is a good thing, maybe the best of things. And no good thing ever dies—— 《The Shawshank Redemption》
前言
作为一个程序开发者，git 是我们常用的一个代码托管工具，它的功能还是很丰富的，所以 Git 的相关操作和命令还是比较多的，可以参看之前的一篇文章：常用的Git命令。
最近在工作中发现，有一部分同学在提交代码的时候还是很不规范的，统一使用了get commit -m "feat: ...."，所有的 commit message 都是使用feat。所以，今天来总结一下Git的提交规范，主要是针对常用的message header
为什么要对 Git 提交日志（message）的格式进行规约约束？
- 更方便、快捷地浏览和了解项目的历史信息
- 有利于保证提交内容的独立性，避免把所有改动都放在一个提交里面
- 便于通过脚本自动化生成
CHANGELOG
Commit message 的基本格式
<type>[optional scope]: <subject>
[optional body]
[optional footer(s)]
其中 message header（即首行）必选，scope、body 和 footer 可选。
字数限制
- header（首行）：只有一行，不超过 50 个字符
- body：每行不超过 72 个字符
- footer：每行不超过 72 个字符
Header
type
type 用来描述本次提交的改动类型，有如下值可以选择：
- feat: 新增功能
- fix: 修复 bug
- docs: 文档相关的改动
- style: 对代码的格式化改动，代码逻辑并未产生任何变化(例如代码缩进，分号的移除和添加。
css样式文件的修改一般属于feat或者fix，并不是style) - test: 新增或修改测试用例
- refactor: 重构代码或其他优化举措
- chore: 项目工程方面的改动，代码逻辑并未产生任何变化
- revert: 恢复之前的提交
scope
scope 用来描述本次提交所涉及到的改动范围（例如：模块、功能或其他任何限定的范围）。
chore(request-utils): add npmignore
subject
subject 用来概括和描述本次提交的改动内容
- 以动词开头，使用第一人称现在时，比如: change，而不是changed或changes
// good
docs: change docs
// bad
docs: changed docs
- 第一个字母小写
- 结尾不加句号（.）
message body和message footer很少用，所以就不再具体多说了（还是偷懒了...）
结语
如果这篇文章帮到了你，欢迎点赞👍和关注⭐️。
文章如有错误之处，希望在评论区指正🙏🙏
欢迎关注我的微信公众号，一起交流技术，微信搜索 🔍 ：「 五十年以后 」
