返回知识库

版本协作 · 版本协作

差异Diff

diff 用 hunk 头和 +/- 标出两版之间哪几行变了;它不负责解释动机或对错,阅读时先定位再看行为,空白噪音要滤掉。

先认出这块 +/- hunk,再判断哪一行才是真改动

下面就是 PR 里那块 unified diff。默认能看见失败时清空密码;空白噪音会用假绿红盖住它;滤掉空白后,真改动重新露出来。

第 0 步先打开:终端跑 git diff,或点 PR 的 Files changed。下面就是那块 unified hunk。

src/auth/login.ts行为变化
@@ -10,3 +10,4 @@ export function login
  const result = api.login(email, password);+  result.catch(() => clearPassword());  return result;

失败时清空密码

先读 hunk 头定位,再看这一行 + 的行为。缺测试:失败路径还没覆盖。

原因:diff 只显示变了哪几行。下一步:看空白噪音怎样盖住真改动,或滤掉空白。

知识点:先读锚点,再读加减号

hunk 上刚走过的阅读顺序。

  • diff 是两版内容的结构化差异:hunk 头 + 上下文 + +/-。
  • 它只告诉你哪几行变了,不告诉你为什么、对不对。
  • 先读 @@ 锚点,再看 +/- 的行为变化,不要数绿行。
  • 空白、锁文件、生成物是噪音,用 -w 或单独看,别掩真改动。

什么时候用、怎么用

提交前、评审中都要先选对比较对象。

  • 信号:要看工作区、暂存区或两个分支之间到底改了什么。
  • 最短路径:选 git diff / --staged / main..feature → 读 hunk 头 → 盯行为 → 噪音用 -w 滤。
  • 不适用:用 diff 代替测试和评审结论;大改动先拆,再逐 hunk 看。

正反例:同一份登录 diff,只改怎么读

都在看 clearPassword,阅读方式不同。

正例先读 hunk 头,再盯 + 的失败路径

发现缺测试,评论写在这一行上,验收「失败登录会清空密码」。

反例数绿行,把缩进当改动

以为改了很多,真正的兜底被空白盖住,漏测失败路径。

快速自测

打开一份 diff,上半是缩进从 2 空格改到 4 空格,下半新增了 clearPassword。你先做什么?

继续查证

术语的技术定义和行为以这些一手或权威资料为准。

下一步学

和本知识点经常一起出现的概念。