拒绝 Git 最佳实践（'git commit -m "fix"' 提交 100 次）

"fix" 提交 100 次？听起来像是某个深夜加班的前端开发者留下的“杰作”。这种看似高效的提交方式，实际上隐藏着巨大的协作灾难和代码管理风险。

为什么 git commit -m "fix" 是灾难性的

假设你正在开发一个 React 组件库，某天你发现了一个按钮样式问题，于是随手提交：

git commit -m "fix"

第二天，你又发现了一个表单验证的 Bug，继续：

git commit -m "fix"

一周后，你的提交历史变成了这样：

commit 1a2b3c4d (HEAD -> main)
Author: Dev <dev@example.com>
Date:   Mon Oct 2 14:30:00 2023 +0800
    fix

commit 5e6f7g8h
Author: Dev <dev@example.com>
Date:   Mon Oct 2 13:15:00 2023 +0800
    fix

commit 9i0j1k2l
Author: Dev <dev@example.com>
Date:   Sun Oct 1 22:45:00 2023 +0800
    fix

这样的提交历史毫无意义，团队成员无法快速理解每次提交的意图，回滚或排查问题时需要逐个检查代码变更，效率极低。

糟糕提交的典型问题

1. 无法追溯变更原因

假设某个 fix 提交引入了新的 Bug，但由于提交信息过于模糊，你无法快速定位是哪个“fix”导致了问题。例如：

// 某次 "fix" 提交修改了这段代码
function calculateTotal(items) {
  return items.reduce((sum, item) => sum + item.price, 0);
  // 原本是 items.reduce((sum, item) => sum + item.price * item.quantity, 0);
}

由于提交信息没有说明修复的是什么问题，后续维护者无法理解为什么 quantity 被移除了。

2. 合并冲突时难以解决

如果多个开发者都在用 fix 提交，在合并分支时，Git 会显示一堆冲突的 fix 提交，你无法快速判断哪些变更应该保留。

3. 代码审查效率低下

代码审查时，Reviewer 需要猜测每次提交的意图，例如：

// 某个 "fix" 提交的变更
- <button className="btn">Submit</button>
+ <button className="btn" disabled={isLoading}>Submit</button>

如果提交信息是 fix: disable button on submit，Reviewer 能立刻理解；但如果只是 fix，就需要额外花时间确认。

如何写出有意义的提交信息

1. 使用约定式提交（Conventional Commits）

约定式提交是一种标准化格式，例如：

feat: add dark mode support
fix: prevent form submission when empty
chore: update dependencies

在团队中强制执行这种格式，可以使用工具如 commitlint 进行校验。

2. 描述“为什么”而不仅是“做了什么”

糟糕的提交信息：

fix: button color

好的提交信息：

fix: adjust primary button color to match design system (#123)

3. 利用 git commit --verbose 查看完整变更

在提交时使用 --verbose 选项，可以在编辑器中看到本次变更的完整 diff，帮助写出更准确的提交信息。

示例：修复一个 React 组件的提交

假设你修复了一个 useEffect 的依赖数组问题：

// Before
useEffect(() => {
  fetchData();
}, []);

// After
useEffect(() => {
  fetchData();
}, [fetchData]);

糟糕的提交：

git commit -m "fix"

好的提交：

git commit -m "fix: add fetchData to useEffect dependencies to prevent stale closure"

工具强制约束

1. 使用 husky + commitlint

在项目中配置 Git Hooks，强制检查提交信息格式：

npm install husky @commitlint/cli @commitlint/config-conventional --save-dev

.commitlintrc.js:

module.exports = {
  extends: ["@commitlint/config-conventional"],
};

package.json:

{
  "husky": {
    "hooks": {
      "commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
    }
  }
}

2. 交互式提交工具

使用 commitizen 引导开发者写出规范的提交信息：

npx commitizen init cz-conventional-changelog --save-dev --save-exact

之后提交时运行 git cz，会进入交互式提交界面。

当历史已经充满“fix”怎么办？

1. 使用 git rebase -i 合并提交

例如，合并最近 5 个 fix 提交：

git rebase -i HEAD~5

在交互式界面中将多个 fix 提交合并为一个有意义的提交。

2. 重写提交信息

使用 git commit --amend 修改最近一次提交信息：

git commit --amend -m "fix: correct responsive layout breakpoints"

前端项目中的典型场景

1. 修复一个 CSS 样式问题

糟糕的提交：

git commit -m "fix"

好的提交：

git commit -m "fix: adjust z-index of modal overlay to prevent stacking context issues"

2. 修复一个 TypeScript 类型错误

糟糕的提交：

git commit -m "fix"

好的提交：

git commit -m "fix: correct UserProfile type to make avatar optional"

团队协作中的提交文化

1. 代码审查时检查提交信息

在 PR 描述中要求关联提交信息，例如：

Related commits:
- feat: add user authentication API
- fix: handle 401 error in login flow

2. 使用 git blame 时更有意义

当运行 git blame 查看某行代码的修改历史时，清晰的提交信息能快速提供上下文：

git blame src/components/Button.tsx

如果提交信息是 fix: button color，你仍然不知道为什么要改；如果是 fix: adjust button color for WCAG contrast compliance，则一目了然。

自动化生成变更日志

清晰的提交信息可以配合工具（如 standard-version）自动生成 CHANGELOG.md：

## [1.2.0] - 2023-10-02
### Features
- Add dark mode support (#45)
### Fixes
- Prevent form submission when empty (#52)

而一堆 fix 提交生成的变更日志毫无价值。

极端情况：真的需要快速提交怎么办？

如果你正在调试一个复杂问题，需要频繁提交，可以使用 git commit --fixup：

git commit --fixup HEAD~1

后续用 git rebase -i --autosquash 自动合并这些临时提交。