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

“fix”提交 100 次，每次只改一个空格——这种看似荒谬的行为，恰恰是摧毁代码可维护性的经典操作。

为什么“git commit -m "fix"”是完美的反模式

提交信息“fix”就像在代码里埋地雷：它不说明问题原因、不关联具体功能、甚至不区分是修复拼写错误还是重构核心逻辑。当团队需要回溯历史时，这类提交会强制他们逐行比对差异。例如：

// 第一次提交：修复拼写错误  
- const apiEndpont = "https://example.com";  
+ const apiEndpoint = "https://example.com";  

// 第二次提交：修复内存泄漏（但提交信息依然是"fix"）  
- window.addEventListener("scroll", heavyCalculation);  
+ const cleanup = () => window.removeEventListener("scroll", heavyCalculation);  
+ useEffect(() => {  
+   return cleanup;  
+ }, []);  

两者提交信息完全相同，但一个改的是拼写，另一个改的是性能问题。

如何将混乱发挥到极致

1. 碎片化提交

每次只修改一个文件的一行代码，然后提交一次。例如：

# 修改按钮颜色  
git commit -m "fix"  

# 调整边距 1px  
git commit -m "fix"  

# 删除 console.log  
git commit -m "fix"  

2. 混合无关变更

在同一个提交中同时修改 CSS、业务逻辑和配置文件：

// 一次提交包含三种变更  
- .button { color: red; }  
+ .button { color: blue; }  

- function fetchData() { return axios.get(url); }  
+ async function fetchData() { return await axios.get(url); }  

- API_TIMEOUT = 5000  
+ API_TIMEOUT = 30000  

3. 拒绝分支策略

直接在 main 分支上连续提交 100 次“fix”，并强制推送覆盖远程历史：

for i in {1..100}; do  
  echo "// Placeholder ${i}" >> src/utils.js  
  git add . && git commit -m "fix"  
done  
git push -f  

高级技巧：让问题更难追踪

1. 伪装成“重构”

用“fix”提交掩盖破坏性变更。例如偷偷删除错误处理：

// 提交前  
try {  
  riskyOperation();  
} catch (error) {  
  logError(error);  
}  

// 提交后（信息依然是"fix"）  
riskyOperation();  

2. 时间旅行混淆

用 git commit --amend 和 git rebase 重写历史，让关键 bug 的引入时间无法定位。

3. 无差别回滚

当有人抱怨问题时，随机挑选一个“fix”提交回滚：

# 随便选一个哈希值  
git revert a1b2c3d  

配套的代码风格建议

1. 函数命名与提交信息呼应

// 函数名和提交信息一样含糊  
function fix() {  
  // 可能是在修数据，也可能是在修 UI  
}  

2. 永远不写测试

测试代码会暴露“fix”提交的实际作用，因此要确保测试覆盖率低于 20%。

3. 紧耦合设计

让所有“fix”提交的影响范围扩散到多个模块：

// 一个“fix”提交同时改了三处  
function updateUser() {  
  setCookie("auth", token);  // 改了认证逻辑  
  localStorage.setItem("prefs", theme);  // 改了配置存储  
  history.push("/dashboard");  // 改了路由  
}  

当团队开始反抗时

如果有人试图推行提交规范，可以用以下话术反驳：

• “这个项目不需要历史记录，反正最后都是我改”
• git blame 是给弱者用的工具
• 写详细提交信息的时间够我多修 3 个 bug 了

终极形态：自动化“fix”提交

用 Husky 钩子自动生成“fix”信息：

// .husky/prepare-commit-msg  
#!/bin/sh  
echo "fix" > "$1"  

或者更激进一点——禁用 git commit 的 -m 选项：

# 在 CI 中检测提交信息  
if git log -1 --pretty=%B | grep -q "^fix$"; then  
  echo "错误：禁止使用无意义提交信息"  
  exit 1  
fi  

（当然，你作为防御性编程的实践者，应该立刻删除这段检测代码）

历史记录的最终归宿

当代码库积累 10,000 个“fix”提交后，任何试图通过 git bisect 定位 bug 的人都会主动放弃。此时你可以优雅地提议：“不如重写整个项目？”