Git diff不止比代码，还能读懂API和JSON

当你对着Git输出的几十行JSON diff皱眉头时，可能没意识到：你需要的不是更仔细地看，而是让Git“换个方式说”。2024年末，一位开发者为了看懂Renovate项目里的依赖数据变更，翻遍文档才搞懂Git自定义diff驱动器——这个能让Git跳过纯文本对比，直接输出结构化差异的功能，居然藏在几乎没人看的角落。为什么明明有更高效的方式，大多数人却还在和无意义的diff噪声较劲？这得从Git diff的底层逻辑说起。

Git diff的底层：从行对比到语义解读

你可以把Git默认的diff算法想象成两个小学生对着课本逐行找不同——它只认文字的增减，不管内容的意义。这个叫Myers的算法诞生于1986年，核心是找出行数最少的修改方式，但在面对JSON、OpenAPI这类结构化文件时，就会把整段代码拆得七零八落，满屏都是无关的逗号和括号。

后来Git补了两个补丁：Patience算法优先匹配唯一的行，避免把空行或括号当成“相同内容”；Histogram算法则会统计行的出现频率，优先对比更有辨识度的内容。但这些都只是“优化找不同的姿势”，没解决根本问题：Git看不懂文件的结构。

直到自定义diff驱动器出现，才给了Git“换个大脑”的可能——你可以让它调用专门的工具，比如用oasdiff对比OpenAPI文件时，直接输出“新增了GET接口”“删除了必填参数”这种人话，而不是一堆YAML代码的增删。

自定义驱动器：7个参数解锁的灵活度

要让Git听话调用外部工具，得先搞懂它递过来的7个“暗号”——这是Git传给自定义驱动器的固定参数：文件名、旧文件路径、旧文件SHA-1、旧文件权限、新文件路径、新文件SHA-1、新文件权限。

别嫌麻烦，这7个参数藏着关键信息：当文件是新增的，旧文件路径会是/dev/null；如果是删除的，新文件路径会变成这个特殊值。你写的脚本只要判断这些标记，就能分别输出“文件新增”“文件删除”，或者调用工具对比两个文件的结构化差异。

配置的逻辑也很清晰：先在.gitattributes里给特定文件类型绑定驱动器名字，比如*.yaml diff=oasdiff；再在Git配置里告诉它这个驱动器对应的命令，比如`[diff

当我们抱怨Git diff不好用时，本质上是在要求版本控制工具跟上文件类型的多样性——从纯代码到API规范，从依赖锁文件到Jupyter笔记本，数据的结构越来越复杂，对比的需求早就不只是“找不同”了。

Git自定义diff驱动器的存在，其实是在提醒我们：工具的灵活性永远比“开箱即用”更重要。它可能配置麻烦，可能受限于安全规则，但它给了我们一个机会——让工具适应我们的工作流，而不是反过来。

一次diff，不只是代码的对比，更是人与工具协作方式的试探。