最开始几行 diff 命令的输出可以这样解释：三个 --- 显示了原来文件的名字；任何在原文件（LCTT 译注：不是源文件）里存在而在新文件里不存在的行将会用前缀 -，用来表示这些行被从源代码里“减去”了。而 +++ 表示的则相反：在新文件里被加上的行会被放上前缀 +，表示这是在新文件里被“加上”的行。补丁文件中的每一个补丁“块”（用 @@ 作为前缀的的部分）都有上下文的行号，这能帮助补丁工具（或其它处理器）知道在代码的哪里应用这个补丁块。你能看到我们已经修改了“Office Space”这部电影里提到的那个函数（移除了三行并加上了一行代码注释），电影里那个有点贪心的工程师可是偷偷的在计算利息的函数里加了点“料”哦。（LCTT译注：剧情详情请见电影 https://movie.douban.com/subject/1296424/）
如果你想找人来测试你的代码改动，你可以将差异保存到一个补丁里：
$ diff-Naur sources-orig/ sources-fixed/>myfixes.patch
现在你有补丁 myfixes.patch 了，你能把它分享给别的开发者，他们可以将这个补丁打在他们自己的源代码树上从而得到和你一样的代码并测试他们。如果一个开发者的当前工作目录就是他的源代码树的根的话，他可以用下面的命令来打补丁：
$ patch-p1 <../myfixes.patch
patching file officespace/interest.go
现在这个开发者的源代码树已经打好补丁并准备好构建和测试文件的修改了。那么如果这个开发者在打补丁之前已经改动过了怎么办？只要这些改动没有直接冲突（LCTT 译注：比如改在同一行上），补丁工具就能自动的合并代码的改动。例如下面的interest.go 文件，它有其它几处改动，然后它想打上 myfixes.patch 这个补丁：
$ patch-p1 <../myfixes.patch
patching file officespace/interest.go
Hunk#1 succeeded at 26(offset 15 lines).
在这个例子中，补丁警告说代码改动并不在文件原来的地方而是偏移了 15 行。如果你文件改动的很厉害，补丁可能干脆说找不到要应用的地方，还好补丁程序提供了提供了打开“模糊”匹配的选项（这个选项在文档里有预置的警告信息，对其讲解已经超出了本文的范围）。
如果你使用 Git 或者 GitHub 的话，你可能不会直接使用补丁或差异。Git 已经内置了这些功能，你能使用这些功能和共享一个源代码树的其他开发者交互，拉取或合并代码。Git 一个比较相近的功能是可以使用 git diff 来对你的本地代码树生成全局差异，又或者对你的任意两次”引用“（可能是一个代表提交的数字，或一个标记或分支的名字，等等）做全局补丁。你甚至能简单的用管道将 git diff 的输出到一个文件里（这个文件必须严格符合将要被使用它的程序的输入要求），然后将这个文件交给一个并不使用 Git 的开发者应用到他的代码上。当然，GitHub 把这些功能放到了 Web 上，你能直接在 Web 页面上查看一个拉取请求的文件变动。在 Web 上你能看到所展示的合并差异，GitHub 还允许你将这些代码改动下载为原始的补丁文件。
总结好了，你已经学到了”差异“和”补丁“是什么，以及在 Unix/Linux 上怎么使用命令行工具和它们交互。除非你还在像 Linux 内核开发这样的项目中工作而使用完全基于补丁文件的开发方式，你应该会主要通过你的源代码控制系统（如 Git）来使用补丁。但熟悉像 GitHub 这样的高级别工具的技术背景和技术底层对你的工作也是大有裨益的。谁知道会不会有一天你需要和一个来自 Linux 世界邮件列表的补丁包打交道呢？