使用 diff 理解代码变更

Dec 16, 2025 · 2 min read

每次代码审查都以相同的方式开始:盯着一堆红色和绿色的行,试图弄清楚到底改变了什么。对于在基于 Git 的工作流中工作的前端开发者来说,快速准确地阅读 diff 是一项核心技能。然而,我们大多数人是通过潜移默化而非刻意练习来学习阅读 diff 的。

本文介绍如何有效地解读代码变更——从理解统一 diff 格式到使用现代工具加快这一过程。

核心要点

统一 diff 格式使用 - 表示删除的行,+ 表示添加的行,并通过 hunk 头部显示变更位置
使用 git diff -w 忽略空格干扰,使用 git diff --staged 在提交前审查变更
像 Difftastic 这样的语义 diff 工具比较代码结构而非原始文本,过滤掉格式化噪音
AI 辅助摘要有助于在审查期间定位,但不应取代仔细的手动检查

理解统一 Diff 格式

统一 diff 格式是你在 git diff 输出和拉取请求界面中看到的内容。流畅地阅读它可以在代码审查期间节省数小时。

典型的 diff 如下所示:

@@ -3,5 +3,6 @@
 import React from 'react';
-const Button = ({ label }) => {
+const Button = ({ label, disabled }) => {
   return (
-    <button>{label}</button>
+    <button disabled={disabled}>{label}</button>
   );

hunk 头部(@@ -3,5 +3,6 @@)告诉你变更发生的位置。-3,5 表示原始文件从第 3 行开始显示 5 行,而 +3,6 表示新版本从第 3 行开始显示 6 行。以 - 开头的行被删除,以 + 开头的行被添加。未标记的行提供上下文——通常是每个变更上下各三行。

上下文行比看起来更重要。它们帮助你理解变更在文件中的位置,而无需打开完整的源代码。

日常工作中的 Git Diff

git diff 命令比较代码的不同状态。最常见的比较:

git diff 显示未暂存的变更与上次暂存版本的对比
git diff --staged 显示你即将提交的内容
git diff main feature-branch 比较分支

对于前端工作,来自 Prettier 等格式化工具的空格变更经常使 diff 变得混乱。使用 git diff -w 忽略空格,或使用 git diff --word-diff 查看行内变更而非整行替换。

在提交前审查自己的工作时,git diff --staged 至关重要。它准确显示下一次提交的内容——不多不少。

现代编辑器中的多文件 Diff

VS Code 和类似编辑器改变了开发者阅读 diff 的方式。你不再需要滚动浏览终端输出,而是获得一个显示变更文件的文件树、内联注释和并排比较。

暂存与未暂存的区别变得可视化。你可以暂存单个 hunk 甚至单行,构建讲述连贯故事的提交,而不是一次性倾倒所有内容。

GitHub 和 GitLab 上的拉取请求界面增加了另一层。逐文件导航、可折叠部分以及绑定到特定行的对话线程使审查大型变更变得可管理。这些 UI 塑造了团队讨论代码的方式——评论附加到 diff 行,而非抽象描述。

用于前端代码库的语义 Diff 工具

传统的基于行的 diff 有一个局限:它们不理解代码结构。在文件中重命名一个变量,你会看到几十行变更,即使语义变更很简单。

像 Difftastic 这样的语义 diff 工具使用 tree-sitter 解析代码,比较抽象语法树而非原始文本。结果是:重新格式化的噪音消失了,实际的逻辑变更突显出来。

对于每次提交都运行 Prettier 的前端代码库,这一点非常重要。语义 diff 工具识别出移动函数或重新格式化 JSX 不是有意义的变更——它显示代码做了什么不同的事情,而不仅仅是看起来有何不同。

这些工具作为自定义 diff 驱动程序与 Git 集成,因此你可以在现有工作流中透明地使用它们。

代码审查中的 AI 辅助 Diff

GitHub Copilot、GitLab 的 AI 功能和第三方工具现在提供 AI 辅助的 diff 摘要。它们生成关于变更内容及其重要性的自然语言解释。

这些摘要在审查不熟悉的代码或大型 PR 时很有帮助。你不需要从分散的 hunk 中拼凑含义,而是获得一个起点:“此 PR 为支付流程添加了错误处理并更新了相关测试。”

但 AI 摘要是起点,而非结论。它们会遗漏只有人类才有的上下文——为什么选择特定方法、存在哪些约束、变更是否符合团队约定。开发者仍需做出最终判断。

实际工作流程:使用 AI 摘要定位自己,然后阅读实际 diff 以验证和理解细节。

结论

有效的 diff 阅读结合了工具知识和刻意练习。理解统一格式,这样终端输出就不会让你感到畏惧。使用编辑器集成进行复杂审查。如果重新格式化的噪音浪费你的时间,考虑使用语义 diff 工具。让 AI 摘要加速定位,但不要取代仔细审查。

目标不是阅读每一行——而是理解变更了什么以及该变更是否正确。更好的工具和更清晰的思维模型能让你更快达到目标。

常见问题

hunk 头部显示两个文件版本的行号和计数。例如,-3,5 表示原始文件从第 3 行开始的 5 行,而 +3,6 表示新版本从第 3 行开始的 6 行。这有助于你在不打开完整文件的情况下定位变更。

使用 git diff -w 忽略空格变更,或使用 git diff --word-diff 仅突出显示行内变更的单词。对于持续的格式化噪音,考虑使用像 Difftastic 这样的语义 diff 工具,它们比较代码结构而非原始文本。

AI 摘要对于定位很有用,特别是对于大型 PR 或不熟悉的代码。但是,它们缺乏项目上下文和团队约定。将它们用作起点,然后在批准变更之前通过阅读实际 diff 自己验证细节。

运行 git diff 显示工作目录中尚未暂存的变更。运行 git diff --staged 显示已暂存并准备提交的变更。使用 --staged 来审查下一次提交中将包含的确切内容。

Gain control over your UX

See how users are using your site as if you were sitting next to them, learn and iterate faster with OpenReplay. — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.