浅浅描述下
在项目开发中，团队开发通常采用 Git 工具来管理版本源代码，代码的变更以及描述会通过 commit 提交保存到代码仓库中，以便跟踪修改记录。
起到什么作用？
- 永久记录到版本库中：通过提交更改，你将它们永久地保存到了 Git 版本库中，这样它们就不会丢失，也可以在以后的时间点进行跟踪或恢复。
- 记录更改历史：每次提交都会包含了更改的详细信息、作者、时间戳等。这样就可以轻松地查看项目的历史记录，并且了解每次更改的内容和原因。
- 支持版本控制：通过提交更改，你可以在项目的不同版本之间进行切换，回滚到先前的版本，或者比较不同版本之间的差异。
- 支持团队协作：通过提交更改并将它们推送到共享的远程仓库，团队成员可以查看你的更改并与之交互。提交信息也使得其他人能够理解你所做的更改，从而更好地协作。
有发现什么问题？
但随着团队人员增多，开发人员对提交代码中的描述风格就难以统一，可能会出现下列情况：
在团队不成熟阶段中，常会出现这种情况，急于下班对代码描述过于简单，或一个分支开发多个功能并一提交描述变动过于模糊，我刚从事行业时，经常这样干的😂。
约定式提交规范：Conventional Commits
在了解 Conventional Commits 之前，我们先看看 Commit 是由哪些结构组成的，下面的内容来自 Conventional Commits 官方规范。
原文：
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]
译文：
<类型>[可选 范围]: <描述>
[可选 正文]
[可选 脚注]
这里我们采用是 @commitlint/config-conventional（基于 Angular 约定），内置配置提交类型有：
- 🛠
build: 用于修改项目构建系统，例如修改依赖库、外部接口或者升级 Node 版本等； - ♻️
chore: 用于对非业务性代码进行修改，例如修改构建流程或者工具配置等； - ⚙️
ci: 用于修改持续集成流程，例如修改 Travis、Jenkins 等工作流配置； - 📚
docs: 用于修改文档，例如修改 README 文件、API 文档等； - 💎
style: 用于修改代码的样式，例如调整缩进、空格、空行等； - 📦
refactor: 用于重构代码，例如修改代码结构、变量名、函数名等但不修改功能逻辑； - 🚀
perf: 用于优化性能，例如提升代码的性能、减少内存占用等； - 🚨
test: 用于修改测试用例，例如添加、删除、修改代码的测试用例等。
当然也可以根据配置文件说明配置其他提交类型，但这里不细讲啦🤭。
讲到这里，大家对 commit 也有个大概了解，接下来我会以教大家如何一步步配置到我们项目中。
配置 Angular 规则（中文版）
安装 Angular 提交规则、Lint 命令行 依赖包
pnpm i -D @commitlint/config-conventional @commitlint/cli
根项目创建.commitlintrc.json 文件，配置如下
{
"extends": ["@commitlint/config-conventional"],
"prompt": {
"settings": {},
"messages": {
"skip": "非必填",
"max": "最大不能超过 %d 个字符！",
"min": "不少于 %d 个字符！",
"emptyWarning": "不能为空！",
"upperLimitWarning": "超过规定范围！",
"lowerLimitWarning": "不符合规定范围！"
},
"questions": {
"type": {
"description": "选择要提交的更改类型：",
"enum": {
"feat": {
"description": "【功能开发】：新功能、新特性",
"title": "Features",
"emoji": "✨"
},
"fix": {
"description": "【问题修复】：bug漏洞、热修复",
"title": "Bug Fixes",
"emoji": "🐛"
},
"docs": {
"description": "【文档维护】：项目描述文档，如：*.md",
"title": "Documentation",
"emoji": "📚"
},
"style": {
"description": "【代码美化】：代码风格，如：单引号、换行、tab缩进",
"title": "Styles",
"emoji": "💎"
},
"refactor": {
"description": "【代码重构】：代码重构，修改项目结构、变量、函数名，不影响业务",
"title": "Code Refactoring",
"emoji": "📦"
},
"perf": {
"description": "【性能优化】：提升代码性能、减少内存占用",
"title": "Performance Improvements",
"emoji": "🚀"
},
"test": {
"description": "【程序测试】：单元测试、测试用例",
"title": "Tests",
"emoji": "🚨"
},
"build": {
"description": "【打包构建】：项目结构、依赖项",
"title": "Builds",
"emoji": "🛠"
},
"ci": {
"description": "【集成流程】：自动化、持续集成、devops配置",
"title": "Continuous Integrations",
"emoji": "⚙️"
},
"chore": {
"description": "【其他修改】：非业务代码修改，如：修改构建流程或者工具配置",
"title": "Chores",
"emoji": "♻️"
},
"revert": {
"description": "【代码回滚】：恢复上一次提交",
"title": "Reverts",
"emoji": "🗑"
}
}
},
"scope": {
"description": "变动范围, 比如: component, utils..."
},
"subject": {
"description": "对变动部分, 描述说明"
},
"body": {
"description": "对变动部分, 请具体描述说明"
},
"isBreaking": {
"description": "是重大变动吗？"
},
"breakingBody": {
"description": "针对重大变化，需要提交详细的描述"
},
"breaking": {
"description": "对重大变化部分, 描述说明"
},
"isIssueAffected": {
"description": "本次变动会影响 issues 问题？"
},
"issuesBody": {
"description": "如果关闭 issues 问题, 请具体描述说明"
},
"issues": {
"description": "创建 issues 问题, 比如: \"fix #123\", \"re #123\"..."
}
}
}
}
安装 husky 依赖包，用于检查 commit 提交规则。
pnpm i -D husky
初始化 husky 配置
pnpm husky init
创建 .husky/commit-msg 文件，配置检查 commit 脚本
#!/usr/bin/env sh
. "$(dirname -- "$0")/_/husky.sh"
pnpm commitlint -e $HUSKY_GIT_PARAMS
试着提交不规范的信息，出现下列情况，就说明配置成功啦。
🎉 恭喜你，配置成功啦！，不过还没完，为了更好地编写提交信息，还需要下列步骤：
配置交互命令
安装 交互命令工具、commitlint适配器 依赖
pnpm i -D commitizen @commitlint/cz-commitlint
根项目创建 .czrc 文件，配置如下
{
"path": "@commitlint/cz-commitlint"
}
在 package.json 文件中，配置交互命令脚本
"scripts": {
...
"commit": "cz"
}
执行交互命令脚本
pnpm commit
出现这种情况，就说明配置成功啦。
