拒绝 "update"：如何写出让同事为你点赞的 Git Commit 记录

Git 提交记录（Commit Message）不仅仅是一行文字，它是代码的历史档案。好的提交记录能让 Code Review 效率倍增，也能在紧急时刻迅速定位问题。今天我们来聊聊，如何从零开始写出一个经得起推敲的 Commit。

基础操作：从暂存到提交

在讨论“写什么”之前，先明确“怎么做”。Git 的提交流程分为两步：

1. 暂存更改 (Stage) Git 不会自动提交工作区的所有改动，你需要先明确告诉它哪些文件需要被记录。

git add .          # 将当前目录下的所有变动添加到暂存区
git add main.py    # 或者只添加特定文件

2. 提交 (Commit) 提交时，推荐两种方式：

• 单行模式：适用于极简单的修改。 git commit -m "你的提交信息"
• 编辑器模式（推荐）：适用于正式开发。 直接输入 git commit（不带 -m），终端会打开默认编辑器（如 Vim 或 VS Code）。这就给了你写多行详细描述的空间，是编写高质量 Commit 的基础。

核心规范：约定式提交

目前业界公认的最佳实践是 Conventional Commits（约定式提交）。只要掌握这个公式，你的提交记录就会立刻变得清晰专业：

<类型>(<范围>): <主题>

<正文>

<脚注>

Header：标题行（必填）

这是最关键的一行，格式为 type(scope): subject。

• Type（类型）：用于说明 commit 的类别。
  • feat: 新增功能 (Feature)
  • fix: 修复 Bug
  • docs: 仅修改文档 (Documentation)
  • style: 格式调整（空格、分号等，不影响代码运行）
  • refactor: 重构（即不是新增功能，也不是修改 bug 的代码变动）
  • perf: 性能优化 (Performance)
  • chore: 构建过程或辅助工具的变动
• Scope（范围）：可选，用于说明影响的模块，例如 user、auth 或 ui。
• Subject（主题）：简要描述改了什么。建议使用祈使句（如 "Add login button"），且结尾不要加句号。

Body：正文（选填）

如果标题行解释不清楚，可以在空一行后编写正文。这里应重点描述 修改动机（Why） 和 修改前的状况，而不是重复代码逻辑。

Footer：脚注（选填）

通常用于关联 Issue 或任务单，例如：Closes #123。

实例演示：好与坏的距离

❌ 错误的写法

git commit -m "修复bug" 问题：过于笼统，无法知道修复了什么内容，回溯成本极高。

✅ 标准的写法（单行）

git commit -m "fix(user): 修复用户无法上传头像的问题" 优点：类型清晰（fix），范围明确（user），行为具体。

✅✅ 专业的写法（完整版） (执行 git commit 进入编辑器编写)

feat(pay): 集成支付宝支付接口

目前系统只支持微信支付，为了满足更多用户需求，新增支付宝渠道。
主要变动：
1. 引入 alipay-sdk
2. 新增 PaymentStrategy 接口实现
3. 更新订单结算页面的 UI 选项

Closes #402

三个黄金法则

为了保持 Git 记录的整洁，请遵守以下原则：

1. 原子性提交 一个 Commit 只做一件事。不要把“修复登录 Bug”和“修改首页样式”混在一个 Commit 里。这样如果样式改错了，回滚时不会影响到登录功能的修复。

2. 善用 Amend 如果你刚提交完发现写错了字，或者漏提了一个文件，不要急着发一个新的 Commit。使用 git commit --amend 可以直接修正上一次的提交记录，保持历史干净。

3. 团队统一语言 中文还是英文其实不重要，重要的是团队内部要统一。对于开源项目或国际化团队，通常建议使用英文。

结语

写好 Commit Message 只需要多花你 30 秒的时间，却能在未来为你和同事节省数小时的排查成本。好的代码体现能力，好的 Commit 记录体现素养。从下一次提交开始，试着加上 feat: 或 fix: 吧。