Git怎么查看文件修改差异_Git diff对比文件变更详解【技巧】

Git diff 对比文件变更详解：从“看不到修改”到精准解读

git diff 看不到修改？检查工作区和暂存区状态

很多开发者第一次遇到 git diff 没反应时都会愣一下：明明改了文件，怎么什么都没显示？其实，这恰恰是理解 Git 设计逻辑的关键一步。

默认情况下，git diff 这个命令只做一件事：对比工作区（就是你正在编辑的文件）和暂存区（执行过 git add 后的状态）。一旦你把修改添加到了暂存区，对于默认的 git diff 来说，这次修改就“消失”了。所以，排查问题的第一步，就是搞清楚你的修改到底处在哪个阶段。

• 想查看那些还没执行 git add 的修改？直接运行 git diff 就行。
• 修改已经暂存了，想看看暂存区和上一次提交有什么不同？这时候得用 git diff --cached（--staged 是它的别名，意思一样）。
• 想一口气看到工作区和暂存区里所有相对于最新提交的改动？git diff HEAD 命令可以满足你。
• 养成个好习惯：在执行 git status 之前，先用上面这几条命令快速扫描一下，你就能对当前所有变更的“分布图层”一目了然。

对比两个分支或提交时，注意方向和含义

当需要比较分支间的差异时，git diff A..B 和 git diff A...B 这两个写法只差一个点，但含义天差地别，用错了很容易得到一堆无关信息。

A..B 表示的是“提交 B 相对于提交 A 的所有变更”。而 A...B 就微妙了，它指的是“提交 B 相对于 A 和 B 的共同祖先的变更”，换句话说，就是 B 分支上独有的那些改动。这个区别在合并或变基后尤其重要。

• 典型场景：你想检查 feature 分支比 main 分支多改了哪些东西。正确的姿势是：git diff main...feature。
• 如果误用了 main..feature，输出里可能会包含大量来自合并历史的、并非 feature 分支独有的修改，特别是在进行过 rebase 操作后，输出会显得非常混乱。
• 对比内容太多刷屏？可以加上文件路径来聚焦，比如 git diff main...feature -- src/utils.js。
• 在全面对比前，先用 --stat 选项看看改动分布是个好主意：git diff --stat main...feature，它能简洁地列出改了哪些文件，以及增删的行数概况。

diff 输出里“a/”“b/”前缀和模式变化是什么意思

初看 git diffdiff --git a/src/index.js b/src/index.js。这里的 a/ 和 b/ 别紧张，它们不是真实的目录，只是 Git 内部用来标记“变更前版本”和“变更后版本”的符号。真正需要关注的是后面跟着的实际文件路径。

有时候，git diff 会输出一些看似奇怪的变化：

• 如果看到 old mode 100644 / new mode 100755 这样的行，别急着看内容——这仅仅表示文件的权限模式变了（例如从普通文件变成了可执行文件），文件内容本身可能毫无改动。
• 遇到提示 Binary files a/image.png and b/image.png differ，意思是 Git 检测到这是二进制文件（如图片），并且它们不同。Git 默认不会展示二进制文件的具体差异。除非你明确知道在做什么，否则不要用 --text 选项去强制当文本比较，对于二进制文件，专门的工具（如 xxd）更合适。
• 差异内容部分，行首的 - 表示删除，+ 表示新增。但要注意，Git 很智能，对于重命名或移动文件，它会进行“相似度检测”。如果看到 similarity index 95% 这样的提示，那说明 Git 认为这是一个文件被移动或重命名了，而不是简单的删除旧文件、新增新文件。

中文文件名乱码或 diff 不生效？查 core.quotePath 和系统编码

在 Windows 或某些 Linux 终端环境下，git diff 输出的中文文件名可能变成像 "\344\270\255\346\226\207.js" 这样的八进制转义序列。这其实不是乱码，而是 Git 的一种保护机制（core.quotePath），它默认会对非 ASCII 字符的路径进行转义。

• 临时解决方案：如果确认你的终端支持 UTF-8 编码，可以关闭这个转义：git config --global core.quotePath false。
• 更根本的调整：让 Git 更好地识别系统编码。例如，在 Windows 上，可以尝试设置：git config --global core.precomposeUnicode true。
• 如果 git diff 完全“无视”某个中文文件的变更，先别怪编码。检查一下这个文件是否被 .gitignore 规则忽略了，或者是否曾经被标记为 assume-unchanged（通过 git update-index --assume-unchanged 命令）。
• Mac 用户有个特殊点：默认的 HFS+ 或 APFS 文件系统是大小写不敏感的，但 Git 默认是大小写敏感的。这可能导致你重命名文件时（仅改变大小写），git diff 无法正确识别出这是一个重命名操作。

说到底，git diff 的复杂性不在于命令本身有多少参数，而在于你能否清晰地告诉 Git 三个问题：“拿什么和什么比？”（工作区、暂存区、提交？）、“比的是什么？”（全部内容、特定路径？）、“路径和编码怎么算？”。把这三个维度理清楚，参数自然就用得对了。