在软件开发过程中，搞清楚“到底改了哪里”是最令人头疼的事情之一。很多新人以为 Git 里有一个专门叫 compare 的命令，但实际上，所有的差异对比功能都封装在 `git diff` 这个指令里。很多时候大家只会用最基本的用法，导致经常看不清改动细节，或者误判了提交内容。这篇文章不讲晦涩的理论，直接用大白话带你拆解 Git 对比功能的各种实战场景。
理解 Git 差异对比的三个核心对象
在使用任何对比命令之前，你的脑子里必须清晰这三个概念：工作区、暂存区和版本库。Git diff 的本质就是在这三者之间做减法。工作区是你电脑里打开文件夹看到的那些正在编辑的文件；暂存区是你执行了 `git add` 后暂时存放的地方；版本库则是你执行了 `git commit` 后永久保存的历史记录。弄清楚了这三者的关系，你就明白为什么有时候 `git diff` 什么都不显示了。
场景一：查看工作区未提交的修改
这是最高频的使用场景。当你写了几百行代码，还没执行 add 操作时，想看看自己到底动了哪些地方。直接输入 `git diff` 即可。这个命令会将当前工作区与暂存区进行对比。如果输出结果显示了大量红色的减号，说明你删除了部分代码；绿色的加号则代表新增的内容。建议在每次准备提交之前，都习惯性跑一遍这个命令，这能有效防止你误删重要文件或引入奇怪的空白字符。
场景二：查看已暂存但未提交的改动
很多开发者会忽略这一点。当你执行了 `git add .` 将所有文件加入暂存区后，此时再敲 `git diff` 会发现没有任何输出，因为工作区和暂存区已经一致了。如果你想检查刚才暂存进去的文件具体改了什么，必须加上 `--staged` 参数，即 `git diff --staged`。这个动作非常重要，它能帮你核对是否不小心把不该提交的大段废弃代码或者是配置文件里的敏感信息给暂存进去了，避免提交后发现还要重新 amend。
场景三：对比两个特定提交记录的差异
有时候你需要回溯历史，或者排查某个 Bug 是什么时候引入的，这就需要对比两个特定的版本。假设你想对比最近一次提交（HEAD）和上一次提交（HEAD~1），可以使用 `git diff HEAD~1 HEAD`。这里的波浪号代表向前追溯的次数。你也可以直接使用具体的 Commit ID 哈希值来进行对比，例如 `git diff abc123 def456`。需要注意的是，命令参数的先后顺序决定了参照物，前面的版本是基准，后面的版本是目标，输出的结果是展示后者相对于前者发生了哪些变化。
场景四：分支合并前的全面体检
在将功能分支合并到主分支之前，通常需要先看看这两个分支之间有哪些差异。标准的语法是使用双点号，例如 `git diff main..feature`。这会让 Git 自动计算两个分支分叉点之后的所有共同祖先，并列出 feature 分支相对于 main 分支的所有新增或修改。这对于 Code Review 环节极其有用，评审人员可以通过这个命令快速了解新代码的逻辑走向，而不用一个个去翻 Commit 日志。
常用辅助参数提升阅读效率
光看满屏的红红绿绿的代码行很容易造成视觉疲劳，配合一些辅助参数能让阅读体验直线上升。如果你只想看改了哪些文件名，而不关心具体内容，可以加上 `--name-only`。如果你想要一个全局概览，知道每个文件增删了多少行，`--stat` 参数会生成一个非常直观的统计列表。在处理重构代码时，如果不希望空格变动干扰视线，可以使用 `--ignore-all-space` 忽略空白字符的变化。此外，`--color-moved` 参数可以将移动位置的代码块高亮显示，对于查找代码搬运痕迹非常有效。
进阶技巧：调用可视化对比工具
命令行虽然强大，但对于复杂的差异对比，图形化界面往往更直观。Git 支持通过 `git difftool` 调用外部工具。你可以预先配置好 meld、kdiff3 或者 VSCode 等编辑器作为对比工具。配置完成后，运行该命令会弹出一个独立的窗口，左侧展示旧版本，右侧展示新版本，中间会有箭头指示变动位置，甚至支持直接点击按钮将右边的内容覆盖到左边。对于大型项目的复杂冲突解决，熟练掌握可视化工具能节省大量时间。
总结来说，Git 对比功能的核心在于找准参照物。无论是查看未提交的草稿，还是复盘历史版本，只要理清工作流并善用参数，你就能对代码变更拥有绝对的掌控力。把这些技巧融入日常习惯，你的 Git 操作水平会有一个质的飞跃。
