歡迎光臨
每天分享高質量文章

差異檔案(diff)和補丁檔案(patch)簡介 | Linux 中國

這篇文章介紹差異檔案(diff)和補丁檔案(patch),以及它們如何在開源專案中使用的例子。
— Phil Estes


致謝
編譯自 | 
https://opensource.com/article/18/8/diffs-patches
 
 作者 | Phil Estes
 譯者 | DavidChenLiang ??共計翻譯:7 篇 貢獻時間:7118 天

這篇文章介紹差異檔案diff補丁檔案patch,以及它們如何在開源專案中使用的例子。

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

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

好了,言歸正傳,程式員嘴裡說的“差異”和“補丁”到底是什麼?

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

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

現在你對補丁和差異就了一個基本的概念,讓我們來看看軟體開發者是怎麼使用這些工具的。如果你還沒有使用過類似於 Git[4] 或 subversion[5] 這樣的原始碼版本控制工具的話,我將會一步步展示最流行的軟體專案是怎麼使用它們的。如果你將一個軟體的生命周期看成是一條時間線的話,你就能看見這個軟體的點滴變化,比如在何時原始碼加上了一個功能,在何時原始碼修複了一個功能缺陷。我們稱這些改變的點為“提交commit”,“提交”這個詞被當今最流行的原始碼版本管理工具 Git 所使用,當你想檢查在一個提交前後的代碼變化的話,(或者在許多個提交之間的代碼變化),你都可以使用工具來觀察檔案差異。

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

Linux、Git 和 GitHub

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

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

該說點乾貨了

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

第一個例子包括一個原始碼樹的兩個不同副本,其中一個有代碼改動,我們想用 diff 來看看這些改動是什麼。這個例子里,我們想看的是“合併格式unified”的補丁,這是現在軟體開發世界里最通用的格式。如果想知道更詳細引數的用法以及如何生成差異檔案,請參考 diff 手冊。原始的代碼在 sources-orig 目錄,而改動後的代碼在 sources-fixed 目錄。如果要在你的命令列上用“合併格式”來展示補丁,請運行如下命令。(LCTT 譯註:引數 -N 代表如果比較的檔案不存在,則認為是個空檔案, -a 代表將所有檔案都作為文本檔案對待,-u 代表使用合併格式並輸出背景關係,-r 代表遞迴比較目錄)

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

……下麵是 diff 命令的輸出:

  1. diff -Naur sources-orig/officespace/interest.go sources-fixed/officespace/interest.go

  2. --- sources-orig/officespace/interest.go        2018-08-10 16:39:11.000000000 -0400

  3. +++ sources-fixed/officespace/interest.go       2018-08-10 16:39:40.000000000 -0400

  4. @@ -11,15 +11,13 @@

  5.    InterestRate float64

  6.  }

  7. +// compute the rounded interest for a transaction

  8.  func computeInterest(acct *Account, t Transaction) float64 {

  9.    interest := t.Amount * t.InterestRate

  10.    roundedInterest := math.Floor(interest*100) / 100.0

  11.    remainingInterest := interest - roundedInterest

  12. -  // a little extra..

  13. -  remainingInterest *= 1000

  14. -

  15.    // Save the remaining interest into an account we control:

  16.    acct.Balance = acct.Balance + remainingInterest

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

如果你想找人來測試你的代碼改動,你可以將差異儲存到一個補丁里:

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

現在你有補丁 myfixes.patch 了,你能把它分享給別的開發者,他們可以將這個補丁打在他們自己的原始碼樹上從而得到和你一樣的代碼並測試他們。如果一個開發者的當前工作目錄就是他的原始碼樹的根的話,他可以用下麵的命令來打補丁:

  1. $ patch -p1 < ../myfixes.patch

  2. patching file officespace/interest.go

現在這個開發者的原始碼樹已經打好補丁並準備好構建和測試檔案的修改了。那麼如果這個開發者在打補丁之前已經改動過了怎麼辦?只要這些改動沒有直接衝突(LCTT 譯註:比如改在同一行上),補丁工具就能自動的合併代碼的改動。例如下麵的interest.go 檔案,它有其它幾處改動,然後它想打上 myfixes.patch 這個補丁:

  1. $ patch -p1 < ../myfixes.patch

  2. patching file officespace/interest.go

  3. 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[17] 選題:lujun9972 譯者:David Chen 校對:wxy

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

赞(0)

分享創造快樂

© 2021 知識星球   网站地图