差異文件（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 程序應用在源代碼樹上。我們能使用 MARKDOWN_HASH2d2dee7af60385a060eae7f556845a8bMARKDOWNHASH 工具來創建「差異」（或「補丁」），然後使用該工具將它們 「打」 在一個沒有這個補丁的同樣的源代碼版本上。此外，（我又要開始跑題說些歷史軼事了……），「補丁」 這個詞真的指在計算機的早期使用打卡機的時候，用來覆蓋在打孔紙帶上來對軟體進行修改的覆蓋紙，那個時代打孔紙帶就是在計算機處理器上運行的程序。下面來自 [維基頁面](https://en.wikipedia.org/wiki/Patch(computing)) 的這張圖真切的描繪了最初的「打補丁」這個詞的出處:

現在你對補丁和差異就了一個基本的概念，讓我們來看看軟體開發者是怎麼使用這些工具的。如果你還沒有使用過類似於 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 世界郵件列表的補丁包打交道呢？

via: https://opensource.com/article/18/8/diffs-patches

作者：Phil Estes 選題：lujun9972 譯者：David Chen 校對：wxy

本文由 LCTT 原創編譯，Linux中國 榮譽推出

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive