GitHub PR 隐藏空白后，为什么改动看起来变少了
只改了一点逻辑，格式化工具却把整个文件的缩进改了，满屏红绿很容易淹没关键变化。GitHub 10月22日公布的改进减少了一个重复动作：个人的空白显示偏好现在可以跨拉取请求保存。
下一份 PR 也沿用这次选择
在 Files changed → Settings → Whitespace changes 中，可以选择 Always show、Always hide 或 Hide for this diff only。保存的偏好属于个人，跨 PR 生效。隐藏时，All commits 旁会出现 Hide whitespace；点 X 可以暂时显示空白，而不改变已保存的偏好。
文件数量和 diff 统计也反映当前显示的差异。因此数字变小，不一定是作者撤回了修改。同一份 PR 的两位读者看到不同数字，可能只是筛选状态不同。
找出格式变化下面的那一行
我们编写了一个计算含税价格的 JavaScript 示例。新版本把结果四舍五入到两位小数，同时把缩进从两个空格改成四个。图片是实际执行本地 git diff 的输出，不是 GitHub 产品界面。
普通 diff 把计算式和 return 一起显示为替换行。使用 git diff -w 后，计算式保留为上下文，return 的变化更醒目。这样更容易讨论舍入规则、负数处理及现有测试。视图更清爽，有助于阅读，但并不证明修改正确。
空白本身也可能改变行为
Python 缩进、YAML 层级以及字符串内的空格都可能有意义。把 "Hello world" 改为 "Helloworld"，用户看到的文字就变了。-w 控制空白比较方式，不会理解编程语言的语义。
在这个刻意简化的字符串例子中，-w 的输出确实为空。第二张图记录了实际运行结果。这不能证明 GitHub 与本地 Git 的所有行为相同，却说明了为什么在空白有意义的地方，应当再展开完整差异。
新文件也能用上更多宽度
在 split view 中，新增和删除的文件现在横跨两列。既然没有旧版放在另一侧，利用全部宽度很自然，也能减少长类型定义和测试名称的折行。
遇到格式和功能混合的 PR，可以先在隐藏空白时阅读逻辑，再显示空白检查字符串和结构。把格式化单独放进一个提交，也有助于传达意图。新偏好减少的是点击和视觉噪声，理解行为仍然是审查的核心。
官方资料
GitHub Docs · Reviewing proposed changes
2026年10月23日核对官方公告及 Git 文档，并在本地执行了两组比较。