清晰的Git提交 Feb 27, 2026
要做到清晰的 Git 提交，核心在于两点：提交的粒度和提交信息的质量。一个清晰的提交历史不仅是你个人的“后悔药”，更是团队协作的“说明书”。
以下是一套可落地执行的最佳实践：
一、 原子性提交
这是清晰的基石。原则是：每次提交只做一件事，且这件事是完整的。
- 不要混合改动： 不要在同一个提交里既修复 Bug，又添加新功能，还调整代码格式。
- ❌ 坏例子：
fix: 修复登录bug并优化了首页样式 - ✅ 好例子：
fix: 修复手机号登录时验证码超时的问题 - ✅ 好例子：
style: 优化首页轮播图的内边距
- ❌ 坏例子：
- 逻辑独立： 一个提交应该代表一个逻辑上的变更。例如，如果要实现一个“用户注册”功能，可以拆分为：
feat: 新增用户注册表单页面feat: 新增注册表单验证逻辑feat: 对接注册API接口
为什么要这么做？
如果某个改动引入了 Bug，你可以通过 git revert 精准地回滚这一个提交，而不影响其他正在开发的功能。
二、 写好提交信息
Git 有一条铁律：Header 是必须的，Body 和 Footer 是可选的。 推荐使用目前业界最流行的 Angular 规范。
1. 提交结构
<type>(<scope>): <subject> // 标题行：必填，不超过50字
// 空一行
<body> // 正文：可选，详细描述改动原因和影响
// 空一行
<footer> // 脚注：可选，记录不兼容变动或关闭的 Issue
2. 如何定义 Type（类型）
这是最常用的部分，直接决定了提交的性质：
- feat：新功能（Feature）。
- fix：修复 Bug。
- docs：仅仅修改了文档，如 README。
- style：修改代码格式（空格、格式化、缺失的分号等），不影响代码逻辑。
- refactor：代码重构（既不是新功能，也不是修 Bug）。
- perf：性能优化。
- test：增加或修改测试用例。
- chore：构建过程或辅助工具的变动（如更新依赖、修改 CI 配置）。
3. 各部分怎么写
- Subject（标题）
- 动词开头：用中文或英文祈使句，如 “Add”、“Fix”，“增加”、“修复”。
- 不超过50字：确保在 Git 日志里一目了然。
- 不加句号：结尾不要加句号。
- Body（正文）
- 回答 Why 而不是 What：代码本身已经说明了“怎么改的”，正文要说清楚“为什么这么改”。
- 对比写法：
- ❌ 无用正文：
修改了变量名 - ✅ 有用正文：
将变量名从 a 改为 userList，因为之前的命名容易与全局变量冲突
- ❌ 无用正文：
示例：
feat(购物车): 增加商品数量上限校验
为防止用户误操作导致下单失败，前端需拦截超过库存的购买数量。
1. 在数量加减组件中增加库存判断
2. 手动输入时触发失焦校验
Closes #1234
三、 提交前的自查清单
在敲下 git commit 命令之前，可以问自己三个问题：
- 能看懂吗？ —— 如果一个月后回来看这条提交，我还能知道改了哪里吗？
- 够小吗？ —— 这个提交能一句话说清楚吗？如果说不清楚，说明改动太杂，应该拆分。
- 能跑吗？ —— 提交的代码应该是能正常编译/运行的。尽量不要提交一个会导致项目崩溃的半成品（除非是在 WIP 分支）。
四、 团队协作技巧
-
使用 rebase 保持线性历史 在将功能分支合并到主分支前，可以使用
git rebase main，而不是直接merge。这样能避免产生大量的“Merge branch”提交记录，让历史看起来像一条直线，更清晰。 - 修复拼写错误不要直接提交
如果你刚提交完，发现有个地方少了个分号或有个拼写错误：
- 修改文件后，使用
git commit --amend。 - 这会把修改合并到上一次提交中，而不是新增一条“修复 typo”的无意义记录。
- 修改文件后，使用
- 养成习惯
刚开始遵循这些规范可能会觉得繁琐，但两周后就会形成肌肉记忆。等到需要查看历史记录排查线上问题，或者需要生成规范的
CHANGELOG.md时，你一定会感谢当初坚持清晰提交的自己。
如果团队对提交规范有统一要求，可以考虑使用 Commitizen 这类工具来交互式地生成符合规范的提交信息。需要我为你介绍一下它的基本用法吗？