這篇文章介紹差異文件diff和補丁文件patch，以及它們如何在開源項目中使用的例子。

如果你曾有機會在一個使用分布式開發模型的大型代碼庫上工作過，你就應該聽說過類似下面的話，“Sue 剛發過來一個補丁patch”，“Rajiv 正在簽出checking out差異diff”, 可能這些詞（補丁、差異文件）對你而言很陌生，而你確定很想搞懂他們到底指什么。開源軟件對上述提到的名詞有很大的貢獻，作為大型項目從 Apache web 服務器到 Linux 內核的開發模型，“基于補丁文件的開發” 這一模式貫穿了上述項目的始終。實際上，你可能不知道 Apache 的名字就來自“一系列的代碼補丁”（LCTT 譯注：Apache 英文發音和補丁的英文 patch 相似)，它們被一一收集起來并針對原來的 NCSA HTTPd server source code 進行了修訂。

你可能認為這只不過是些逸聞，但是一份早期的 Apache 網站的存檔中 聲稱 Apache 的名字就是來自于最早的“補丁”集合；即“打了補丁的APAtCHy”服務器，簡化為 Apache。

好了，言歸正傳，程序員嘴里說的“差異”和“補丁”到底是什么？

首先，在這篇文章里，我們可以認為這兩個術語都指向同一個概念。“diff” 是 ”difference“ 的簡寫；Unix 下的同名工具程序 diff剖析了一個或多個文件之間的“差異”。下面我們會看到 diff 的例子:

一個“補丁”指的是文件之間一系列差異，這些差異能被 Unix 的 diff 程序應用在源代碼樹上。我們能使用 diff 工具來創建“差異”（或“補丁”），然后使用該工具將它們 “打” 在一個沒有這個補丁的同樣的源代碼版本上。此外，（我又要開始跑題說些歷史軼事了……），“補丁” 這個詞真的指在計算機的早期使用打卡機的時候，用來覆蓋在打孔紙帶上來對軟件進行修改的覆蓋紙，那個時代打孔紙帶就是在計算機處理器上運行的程序。下面來自 維基頁面 的這張圖真切的描繪了最初的“打補丁”這個詞的出處:

[[243388]]

現在你對補丁和差異就了一個基本的概念，讓我們來看看軟件開發者是怎么使用這些工具的。如果你還沒有使用過類似于 Git 或 subversion 這樣的源代碼版本控制工具的話，我將會一步步展示***的軟件項目是怎么使用它們的。如果你將一個軟件的生命周期看成是一條時間線的話，你就能看見這個軟件的點滴變化，比如在何時源代碼加上了一個功能，在何時源代碼修復了一個功能缺陷。我們稱這些改變的點為“提交commit”，“提交”這個詞被當今***的源代碼版本管理工具 Git 所使用，當你想檢查在一個提交前后的代碼變化的話，（或者在許多個提交之間的代碼變化），你都可以使用工具來觀察文件差異。

如果你同樣在使用 Git 開發軟件的話，你可以在你的本地開發環境做些希望交給別的開發者的提交，以添加到他們的源代碼樹中。為了給別的開發者你的提交，一個方法就是創建一個你本地文件的差異文件，然后將這個“補丁”發送給和你工作在同一個源代碼樹的別的開發者。別的開發者在“打”了你的補丁之后，就能看到在你的代碼變樹上的變化。 

Linux、Git 和 GitHub

這種分享補丁的開發模型正是現今 Linux 內核社區如何處理內核修改提議而采用的模型。如果你有機會瀏覽任何一個主流的 Linux 內核郵件列表 —— 主要是 LKML，也包括 linux-containers、fs-devel、Netdev 等等，你能看到很多開發者會貼出他們想讓其他內核開發者審核、測試或者合入 Linux 官方 Git 代碼樹某個位置的補丁。當然，討論 Git 不在這篇文章范圍之內（Git 是由 Linus Torvalds 開發的源代碼控制系統，它支持分布式開發模型以及允許獨立于主要代碼倉庫的補丁包，這些補丁包能被推送或拉取到不同的源代碼樹上，并遵守這些代碼樹各自的開發流程。）

在繼續我們的話題之前，我們當然不能忽略和補丁和差異這個概念相關的***的服務：GitHub。從它的名字就能猜想出 GitHub 是基于 Git 的，而且它還圍繞著 Git 對分布式開源代碼開發模型提供了基于 Web 和 API 的工作流管理。（LCTT 譯注：即拉取請求Pull Request）。在 GitHub 上，分享補丁的方式不是像 Linux 內核社區那樣通過郵件列表，而是通過創建一個 拉取請求 。當你提交你自己的源代碼樹的改動時，你能通過創建一個針對軟件項目的共享倉庫的“拉取請求”來分享你的代碼改動（LCTT 譯注：即核心開發者維護一個主倉庫，開發者去“復刻fork”這個倉庫，待各自的提交后再創建針對這個主倉庫的拉取請求，所有的拉取請求由主倉庫的核心開發者批準后才能合入主代碼庫。）GitHub 被當今很多活躍的開源社區所采用，如 Kubernetes、Docker、容器網絡接口 (CNI)、Istio 等等。在 GitHub 的世界里，用戶會傾向于使用基于 Web 頁面的方式來審核一個拉取請求里的補丁或差異，你也可以直接訪問原始的補丁并在命令行上直接使用它們。 

該說點干貨了

我們前面已經講了在流行的開源社區里是怎么應用補丁和差異的，現在看看一些例子。

***個例子包括一個源代碼樹的兩個不同副本，其中一個有代碼改動，我們想用 diff 來看看這些改動是什么。這個例子里，我們想看的是“合并格式unified”的補丁，這是現在軟件開發世界里最通用的格式。如果想知道更詳細參數的用法以及如何生成差異文件，請參考 diff 手冊。原始的代碼在 sources-orig 目錄，而改動后的代碼在 sources-fixed 目錄。如果要在你的命令行上用“合并格式”來展示補丁，請運行如下命令。（LCTT 譯注：參數 -N 代表如果比較的文件不存在，則認為是個空文件， -a 代表將所有文件都作為文本文件對待，-u 代表使用合并格式并輸出上下文，-r 代表遞歸比較目錄）

$ diff -Naur sources-orig/ sources-fixed/

……下面是 diff 命令的輸出：

diff -Naur sources-orig/officespace/interest.go sources-fixed/officespace/interest.go
--- sources-orig/officespace/interest.go        2018-08-10 16:39:11.000000000 -0400
+++ sources-fixed/officespace/interest.go       2018-08-10 16:39:40.000000000 -0400
@@ -11,15 +11,13 @@
   InterestRate float64
 }
 
+// compute the rounded interest for a transaction
 func computeInterest(acct *Account, t Transaction) float64 {
 
   interest := t.Amount * t.InterestRate
   roundedInterest := math.Floor(interest*100) / 100.0
   remainingInterest := interest - roundedInterest
 
-  // a little extra..
-  remainingInterest *= 1000
-
   // Save the remaining interest into an account we control:
   acct.Balance = acct.Balance + remainingInterest

最開始幾行 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 世界郵件列表的補丁包打交道呢？