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

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

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

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

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

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

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

Linux、Git 和 GitHub

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

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

該說點干貨了

我們前面已經(jīng)講了在流行的開源社區(qū)里是怎么應(yīng)用補(bǔ)丁和差異的，現(xiàn)在看看一些例子。

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

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

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

最開始幾行 diff 命令的輸出可以這樣解釋：三個 --- 顯示了原來文件的名字；任何在原文件（LCTT 譯注：不是源文件）里存在而在新文件里不存在的行將會用前綴 -，用來表示這些行被從源代碼里“減去”了。而 +++ 表示的則相反：在新文件里被加上的行會被放上前綴 +，表示這是在新文件里被“加上”的行。補(bǔ)丁文件中的每一個補(bǔ)丁“塊”（用 @@ 作為前綴的的部分）都有上下文的行號，這能幫助補(bǔ)丁工具（或其它處理器）知道在代碼的哪里應(yīng)用這個補(bǔ)丁塊。你能看到我們已經(jīng)修改了“Office Space”這部電影里提到的那個函數(shù)（移除了三行并加上了一行代碼注釋），電影里那個有點貪心的工程師可是偷偷的在計算利息的函數(shù)里加了點“料”哦。（LCTT譯注：劇情詳情請見電影 https://movie.douban.com/subject/1296424/）

如果你想找人來測試你的代碼改動，你可以將差異保存到一個補(bǔ)丁里：

$ diff -Naur sources-orig/ sources-fixed/ >myfixes.patch

現(xiàn)在你有補(bǔ)丁 myfixes.patch 了，你能把它分享給別的開發(fā)者，他們可以將這個補(bǔ)丁打在他們自己的源代碼樹上從而得到和你一樣的代碼并測試他們。如果一個開發(fā)者的當(dāng)前工作目錄就是他的源代碼樹的根的話，他可以用下面的命令來打補(bǔ)?。?/p>

$patch -p1 < ../myfixes.patch

patching file officespace/interest.go

現(xiàn)在這個開發(fā)者的源代碼樹已經(jīng)打好補(bǔ)丁并準(zhǔn)備好構(gòu)建和測試文件的修改了。那么如果這個開發(fā)者在打補(bǔ)丁之前已經(jīng)改動過了怎么辦？只要這些改動沒有直接沖突（LCTT 譯注：比如改在同一行上），補(bǔ)丁工具就能自動的合并代碼的改動。例如下面的interest.go 文件，它有其它幾處改動，然后它想打上 myfixes.patch 這個補(bǔ)?。?/p>

$patch -p1 < ../myfixes.patch

patching file officespace/interest.go

Hunk#1 succeeded at 26 (offset 15 lines).

在這個例子中，補(bǔ)丁警告說代碼改動并不在文件原來的地方而是偏移了 15 行。如果你文件改動的很厲害，補(bǔ)丁可能干脆說找不到要應(yīng)用的地方，還好補(bǔ)丁程序提供了提供了打開“模糊”匹配的選項（這個選項在文檔里有預(yù)置的警告信息，對其講解已經(jīng)超出了本文的范圍）。

如果你使用 Git 或者 GitHub 的話，你可能不會直接使用補(bǔ)丁或差異。Git 已經(jīng)內(nèi)置了這些功能，你能使用這些功能和共享一個源代碼樹的其他開發(fā)者交互，拉取或合并代碼。Git 一個比較相近的功能是可以使用 git diff 來對你的本地代碼樹生成全局差異，又或者對你的任意兩次”引用“（可能是一個代表提交的數(shù)字，或一個標(biāo)記或分支的名字，等等）做全局補(bǔ)丁。你甚至能簡單的用管道將 git diff 的輸出到一個文件里（這個文件必須嚴(yán)格符合將要被使用它的程序的輸入要求），然后將這個文件交給一個并不使用 Git 的開發(fā)者應(yīng)用到他的代碼上。當(dāng)然，GitHub 把這些功能放到了 Web 上，你能直接在 Web 頁面上查看一個拉取請求的文件變動。在 Web 上你能看到所展示的合并差異，GitHub 還允許你將這些代碼改動下載為原始的補(bǔ)丁文件。

總結(jié)

好了，你已經(jīng)學(xué)到了”差異“和”補(bǔ)丁“是什么，以及在 Unix/Linux 上怎么使用命令行工具和它們交互。除非你還在像 Linux 內(nèi)核開發(fā)這樣的項目中工作而使用完全基于補(bǔ)丁文件的開發(fā)方式，你應(yīng)該會主要通過你的源代碼控制系統(tǒng)（如 Git）來使用補(bǔ)丁。但熟悉像 GitHub 這樣的高級別工具的技術(shù)背景和技術(shù)底層對你的工作也是大有裨益的。誰知道會不會有一天你需要和一個來自 Linux 世界郵件列表的補(bǔ)丁包打交道呢？