Git 历史回顾

Git 历史回顾

Git 历史是一座金矿——里面藏着「为什么这么改」「谁动了什么」「这个 commit 是不是埋了雷」的全部答案。但很少有人愿意挖，因为 git log 出来全是 wip、fix typo、as discussed，长得让人头大。

Claude Code 是个不知疲倦的矿工。你把历史喂给它，它替你读、替你总结、替你判断风险。这一篇讲怎么用 @git 把 Claude 变成你的 Git 历史分析师。

第一招：读单个 commit——是干啥的，有没有风险

接手一个项目，最常问的两个问题是「这个 commit 改了啥」和「它有没有可能引入风险」。直接 @git：

Explain what this commit does and whether it introduces risk: @git show a3f2c1e

Claude 会：

1. 读 commit 的 diff
2. 总结「这次改动干了什么」
3. 评估风险——是否改了公共 API、是否动了并发逻辑、是否引入新的依赖、是否有测试覆盖

@git 是 Claude Code 的文件引用语法——它会把后面的命令（git show a3f2c1e）跑一遍，输出塞进上下文，然后回答你的问题。比你自己 git show 然后粘给 Claude 高效一步。

风险信号有哪些？Claude 会盯这些：

• 改了接口签名——下游可能崩
• 改了并发控制（锁、原子操作、async/await 顺序）——死锁、竞态风险
• 删了错误处理——异常会冒到上层
• 改了默认值——依赖默认行为的调用方行为变了
• 没有对应测试——这改动没人验证过

每个 commit 都能用这一招过一遍。挑你担心的几个重点查。

第二招：总结最近 N 个 commit——意图是什么

光看单个 commit 不够，你要看一段历史整体在干什么。这是判断「这个分支想解决什么问题」的关键：

Summarize the intent of the last 5 commits: @git log -5 --patch

--patch 让输出包含每个 commit 的完整 diff——内容多，但 Claude 能消化。它会给你一份按 commit 切分的总结：

• commit 1 (abc123): 加了用户注销接口，路由 /logout，加了对应测试。意图：实现注销功能。
• commit 2 (def456): 重构 token 验证，从同步改异步。意图：性能优化，注意：调用方执行时机变了。
• commit 3 (ghi789): 修了空购物车结账的 TypeError。意图：bugfix，加了空数组检查。
• commit 4 (jkl012): 更新 README，加了 docker 部署说明。意图：文档。
• commit 5 (mno345): 升级依赖 lodash 到 4.17.21。意图：安全补丁，注意：lodash 4.x 与 3.x 有 breaking change。

注意最后那个「注意」——Claude 会主动标出风险信号：行为变更、breaking change、并发改动。这是单纯 git log 给不了你的判断。

第三招：让 Claude 区分重构 vs 行为变更

这是读 Git 历史最有价值的一招——判断哪些 commit 是纯重构，哪些改了行为。

为什么这事重要？因为：

• 纯重构的 commit 风险低，可以放心 cherry-pick 或 revert
• 行为变更的 commit 风险高，cherry-pick 后可能影响其他逻辑
• 声称重构实则改行为的 commit 最危险——审查者以为它在重构，没仔细看，结果埋了雷

让 Claude 当这个审查者：

classify the last 10 commits into three buckets:
1. pure refactor (structure changed, behavior preserved)
2. behavior change (output / side effects / timing differs)
3. ambiguous (can't tell without running tests)

for each, give one-line justification. flag any commit message that says "refactor" but actually changes behavior

最后一句「flag any commit message that says refactor but actually changes behavior」是这一招的精华——它专挑伪装成重构的行为变更。这种 commit 在历史里最阴险，因为代码审查时大家都以为「哦，refactor，没事」就放过了。

第四招：整理 commit 历史——让历史更可读

提 PR 前，如果 commit 历史乱七八糟（一堆 wip、fix typo、fix fix typo），审查体验会很差。让 Claude 给你整理建议：

Suggest a cleaner commit history based on these changes: @git log --patch main..HEAD

propose an interactive rebase plan that:
- squashes typo fixes into their parent feature commit
- reorders commits so each is independently meaningful
- rewrites messages following Conventional Commits (feat/fix/refactor/docs/test)
- keeps each commit's diff buildable and testable

don't execute the rebase — just propose it

「don’t execute the rebase」很重要——让 Claude 只建议不执行。Interactive rebase 是有破坏性的操作，最终决定和执行权在你手里。Claude 给你方案，你审计后自己跑 git rebase -i。

第五招：重构前确认依赖关系

你想重构某个函数，但不知道历史上谁动过它、为什么动。先让 Claude 看历史：

list every commit that touched src/auth/refresh.ts in the last year: @git log --since="1 year ago" --oneline -- src/auth/refresh.ts

for each, summarize:
- what was changed
- why (from commit message and diff context)
- whether it was a fix, refactor, or feature

flag any commit that looks like it patched a symptom rather than the root cause — those are signals of fragile code I should be careful with

最后一句「patched a symptom rather than the root cause」是这招的精华——它让 Claude 找出历史上「治标不治本」的修复，因为这些地方往往是脆弱代码的重灾区。一个函数被「临时修」了五次，每次都是 + if (x) return，那它内部逻辑肯定乱得可以——重构时要格外小心。

三个常见场景

整理 PR 前的历史

I'm about to open a PR. review the commit history of this branch: @git log main..HEAD --patch

propose:
1. which commits should be squashed
2. which should be split (multi-concern commits)
3. which have misleading messages that need rewriting
4. final commit order and messages

don't execute — just propose

回顾一段历史找 bug 引入点

a bug was reported in production. the last known good commit is abc1234.
walk the history from abc1234 to HEAD: @git log abc1234..HEAD --patch

identify the commit most likely to have introduced the bug, based on:
- changes to code paths in the bug's stack trace
- changes that lack tests
- changes labeled "refactor" that might have altered behavior
rank the top 3 suspects with reasoning

重构前的依赖盘点

I'm planning to refactor src/payment/checkout.py.
- list every file that imports from it (use grep)
- list every commit in the last 6 months that touched it
- identify the public API (functions imported elsewhere)
- flag any function that has been modified >5 times — likely fragile
this informs my refactor plan

一份 Git 历史回顾模板

Task: review the Git history of [branch / file / time range]

1. @git log --patch [range] — full diff history
2. summarize each commit: what changed, why, type (feat/fix/refactor/docs)
3. classify: pure refactor vs behavior change vs ambiguous
4. flag risks:
   - commits without tests
   - commits labeled "refactor" that changed behavior
   - commits patching symptoms, not root causes
5. propose: history cleanup if messy, or focus areas if reviewing for risk

填空，丢给 Claude，得到一份比 git log 强十倍的历史回顾。

下一站

• 想在 PR 审查里用类似思路——看 代码审查流水线。
• 重构前要先理解依赖——读 重构遗留代码。
• @ 引用的完整语法——回顾 @ 文件引用。