8 月初，當(dāng) Linux 5.8 RC 版本開(kāi)放測(cè)試時(shí)，大多數(shù)的新聞都聚焦于它的大小，稱其為“史上最大的內(nèi)核版本”。正如 Linus Torvalds 本人指出的那樣，“盡管沒(méi)有任何一件事情能脫穎而出……但 5.8 似乎是我們有史以來(lái)最大的發(fā)行版之一?！?/p>

確實(shí)，剛剛發(fā)布的 Linux 內(nèi)核 5.8 RC 具有超過(guò) 14，000 個(gè) commit，約 80 萬(wàn)行新代碼以及大約 100 名新貢獻(xiàn)者。要知道，距離 5.7 正式版發(fā)布才僅僅過(guò)去了約 2 個(gè)月的時(shí)間。Linux 內(nèi)核維護(hù)者 Steven Rostedt 認(rèn)為，5.8 之所以變得如此之大，很有可能是因?yàn)?COVID-19 疫情讓很多人難以出門(mén)旅行，所有人都因此能夠在這期間完成比平時(shí)更多的工作。

Rostedt 表示，從一個(gè)經(jīng)驗(yàn)豐富的 Linux 內(nèi)核貢獻(xiàn)者和維護(hù)者的角度來(lái)看，5.8 RC 發(fā)行版特別令人震驚的并不是它的大小，而是它的空前規(guī)模對(duì)于那些正在維護(hù)它的人來(lái)說(shuō)卻沒(méi)有造成困擾，“我認(rèn)為這是因?yàn)?Linux 具有比世界上任何軟件項(xiàng)目都好的工作流程?！?/p>

擁有最佳的工作流程意味著什么？對(duì) Rostedt 而言，這歸結(jié)為 Linux 內(nèi)核開(kāi)發(fā)人員隨著時(shí)間的推移建立的一系列基本規(guī)則，以使他們能夠持續(xù)不斷地大規(guī)模、可靠地發(fā)展 Linux 內(nèi)核項(xiàng)目。Rostedt 站在一個(gè) Linux 內(nèi)核資深維護(hù)者的角度，為我們分享了龐大的 Linux 內(nèi)核項(xiàng)目 30 年來(lái)是如何有條不紊地運(yùn)轉(zhuǎn)的。

第一個(gè)關(guān)鍵因素是 Git

首先讓我們從 Linux 項(xiàng)目的歷史來(lái)看。在該項(xiàng)目的早期（1991-2002年），人們只能直接將補(bǔ)丁發(fā)送給 Linus Torvalds。準(zhǔn)確地說(shuō)，Linus 從項(xiàng)目的子維護(hù)者那里獲取補(bǔ)丁，而這些子維護(hù)者從其他代碼貢獻(xiàn)者那里獲取補(bǔ)丁。隨著 Linux 內(nèi)核變得越來(lái)越大，代碼越來(lái)越復(fù)雜，很快他們就發(fā)現(xiàn)，一切都變得很難擴(kuò)展和跟蹤，并且項(xiàng)目將始終面臨合并不兼容代碼的風(fēng)險(xiǎn)。

這導(dǎo)致 Linus 開(kāi)始探索包括 BitKeeper 在內(nèi)的各種版本管理工具。BitKeeper 是一種最早的分布式版本管理的方法，其他的版本管理系統(tǒng)通常使用簽出/修改/簽入?yún)f(xié)議，而 BitKeeper 則向所有人提供整個(gè)倉(cāng)庫(kù)的副本，并允許開(kāi)發(fā)人員將其變更發(fā)送出去以進(jìn)行合并。Linux 在 2002 年開(kāi)始短暫地采用了 BitKeeper，但是由于其本身是一個(gè)專(zhuān)有軟件，被認(rèn)為不符合社區(qū)對(duì)開(kāi)源工作的信念，于是該工具在 2005 年停止使用。為了尋找替代品，Linus 消失了一段時(shí)間，并帶著 git 回來(lái)了，后者成為了更強(qiáng)大的分布式版本管理系統(tǒng)，并且是管理流程的第一個(gè)重要實(shí)例化。Git 的出現(xiàn)使 Linux 開(kāi)發(fā)在今天依然運(yùn)轉(zhuǎn)良好。

Rostedt 為我們列出了 Linux 內(nèi)核工作流程中，圍繞 Git 展開(kāi)的七個(gè)重要基本原則。

七大基本原則

每次commit只能做一件事

Linux 的中心原則是，所有更改都必須分解為小步驟進(jìn)行 —— 您的每個(gè)commit都只能做一件事。這并不意味著每個(gè) commit 都必須很小，比如對(duì)在數(shù)千個(gè)文件中使用的函數(shù)的API進(jìn)行簡(jiǎn)單更改，可以使更改量很大，但仍然可以接受，因?yàn)樗轻槍?duì)某一項(xiàng)單一任務(wù)的更改。通過(guò)始終遵循此原則，項(xiàng)目維護(hù)者可以更輕松地識(shí)別和隔離任何有問(wèn)題的更改，而不影響其他的功能。

commit 不能破壞構(gòu)建

不僅應(yīng)該將所有更改分解為盡可能小的變量，而且還不能破壞內(nèi)核。即每個(gè)步驟都必須完全起作用，并且不引起退化。這就是為什么對(duì)函數(shù)原型的更改還必須更新調(diào)用它的每個(gè)文件，以防止構(gòu)建中斷的原因。因此，每個(gè)步驟都必須作為一個(gè)獨(dú)立的更改來(lái)工作，這將我們帶到了下一點(diǎn)：

所有代碼都是二等分的

如果在某個(gè)時(shí)候發(fā)現(xiàn)了錯(cuò)誤，則需要知道是哪個(gè)更改導(dǎo)致了問(wèn)題。從本質(zhì)上講，二等分是一種操作，它使開(kāi)發(fā)者可以找到所有發(fā)生錯(cuò)誤的確切時(shí)間點(diǎn)。

為此，請(qǐng)轉(zhuǎn)到最后一個(gè)已知的工作 commit 所在的節(jié)點(diǎn)，并且已知第一個(gè) commit 已損壞，然后在該點(diǎn)測(cè)試代碼。如果可行，則前進(jìn)到下一個(gè)節(jié)點(diǎn)；如果不是，則返回更上層的節(jié)點(diǎn)。這樣一來(lái)，開(kāi)發(fā)者就可以在十幾次編譯/測(cè)試中，從成千上萬(wàn)的可能 commit 中分離出導(dǎo)致問(wèn)題出現(xiàn)的 commit 。Git 甚至可以通過(guò) git bisect 功能幫助自動(dòng)化該過(guò)程。

重要的是，這只有在開(kāi)發(fā)者遵守以前的規(guī)則的情況下才能很好地起作用：每個(gè) commit 僅做一件事。否則，您將不知道是 commit 的許多更改中的哪一個(gè)導(dǎo)致了問(wèn)題；如果 commit 破壞了構(gòu)建讓整個(gè)項(xiàng)目無(wú)法正常啟動(dòng)，同時(shí)等分線又恰好落在了該 commit 上，則您將不知道接下來(lái)是該往上一個(gè)節(jié)點(diǎn)測(cè)試還是往下一個(gè)節(jié)點(diǎn)測(cè)試，因?yàn)樗鼈兌加袉?wèn)題。這意味著您永遠(yuǎn)都不應(yīng)編寫(xiě)依賴于將來(lái) commit 的 commit ，例如：調(diào)用尚不存在的函數(shù)，或更改全局函數(shù)的參數(shù)而不更改同一 commit 中的所有調(diào)用者。

永遠(yuǎn)不要 rebase 公共分支

Linux 項(xiàng)目工作流程不允許 rebase 他人使用的任何公共分支。因?yàn)?rebase 這些公共分支后，已重新基準(zhǔn)化的 commit 將不再與基于原存儲(chǔ)庫(kù)中的相同 commit 匹配。在樹(shù)的層次結(jié)構(gòu)中，不是葉子的公共主干部分不能重新設(shè)置基準(zhǔn)，否則將會(huì)破壞層次結(jié)構(gòu)中的下游分支。

Git 正確合并

其他的版本管理系統(tǒng)是合并來(lái)自不同分支代碼的噩夢(mèng)，它們通常難以弄清代碼沖突，并且需要大量的手動(dòng)工作來(lái)解決。而 Git 的結(jié)構(gòu)可以輕松完成這項(xiàng)工作，因此 Linux 項(xiàng)目也從中直接受益。這就是為什么 5.8 版本的大小并不重要的重要原因。在 5.8-RC1 發(fā)布周期中，平均每天有 200個(gè) commit ，并從 5.7 版本中繼承了 880 個(gè)合并。一些維護(hù)者注意到了其中增加的工作量，但是對(duì)此仍然沒(méi)有感到什么太大的壓力或者導(dǎo)致倦怠。

保留定義明確的 commit 日志

不幸的是，這可能是許多其他項(xiàng)目忽略的最重要的原則之一。每個(gè) commit 都必須是獨(dú)立的，這也應(yīng)該包括與該 commit 相應(yīng)的日志。內(nèi)核貢獻(xiàn)者必須在更改的 commit 日志中做出說(shuō)明，讓所有人了解與正在進(jìn)行的更改相關(guān)的所有內(nèi)容。Rostedt 提到，他自己的一些最冗長(zhǎng)和最具描述性的變更日志，往往是針對(duì)一些單行代碼提交的，因?yàn)檫@些單行代碼更改是非常細(xì)微的錯(cuò)誤修復(fù)，且代碼本身包含的信息極少。因此更改的代碼越少，日志反而應(yīng)該說(shuō)明得更詳細(xì)。

在一個(gè) commit 過(guò)了幾年之后，幾乎沒(méi)有人會(huì)記得當(dāng)初為什么進(jìn)行更改。Git 的 blame 功能就可以顯示這些代碼的修改記錄。比如一些 commit 可能非常古老，也許您需要去除一個(gè)鎖定，或者對(duì)某些代碼進(jìn)行更改，而又不確切知道它為什么存在，就可以使用 git blame 來(lái)查看。編寫(xiě)良好的代碼更改日志可以幫助確定是否可以刪除該代碼或如何對(duì)其進(jìn)行修改。Rostedt 說(shuō)：“有好幾次我很高興能在代碼上看到詳細(xì)的變更日志，因?yàn)槲也坏貌粍h除這些代碼，而變更日志的描述讓我知道我這么做是可以的?！?/p>

持續(xù)測(cè)試和集成

最后一項(xiàng)基本原則是開(kāi)發(fā)過(guò)程中進(jìn)行持續(xù)測(cè)試和持續(xù)集成。在向上游發(fā)送 commit 請(qǐng)求之前，開(kāi)發(fā)者會(huì)測(cè)試每個(gè) commit 。Linux 社區(qū)還有一個(gè)名為 Linux-next 的鏡像 ，它提取維護(hù)人員在其存儲(chǔ)庫(kù)的特定分支上進(jìn)行的所有更改，并對(duì)其進(jìn)行測(cè)試以確保它們能正確集成。Linux-next 非常有效地運(yùn)行著整個(gè)內(nèi)核的可測(cè)試分支，該分支將用于下一個(gè)發(fā)行版。Linux-next 是一個(gè)公共倉(cāng)庫(kù)，任何人都可以測(cè)試它，這種情況經(jīng)常發(fā)生 —— 人們現(xiàn)在甚至發(fā)布有關(guān) Linux-next 中代碼的錯(cuò)誤報(bào)告。事實(shí)上，已經(jīng)進(jìn)入 Linux-next 幾周的代碼基本上可以確定會(huì)最終進(jìn)入主線發(fā)行版中。

軟件開(kāi)發(fā)行業(yè)的黃金標(biāo)準(zhǔn)

所有的這些原則制度使 Linux 社區(qū)能夠以如此龐大的規(guī)模（常規(guī) 9 周為一個(gè)版本迭代周期）發(fā)布令人難以置信的可靠代碼（每個(gè)版本平均 10，000 次 commit ，最后一個(gè)版本超過(guò) 14，000 次 commit ）。

Rostedt 指出，Linux 項(xiàng)目取得空前成功的另一個(gè)因素是他們社區(qū)的文化。Linux 內(nèi)核社區(qū)內(nèi)部存在一種持續(xù)改進(jìn)的文化，這使他們能夠首先采用這些實(shí)踐。同時(shí)他們還有一種信任的文化，“我們有一條清晰的途徑，人們可以通過(guò)該途徑做出貢獻(xiàn)，并隨著時(shí)間的推移證明他們?cè)敢馇矣心芰ν七M(jìn)該項(xiàng)目的發(fā)展。這將建立一個(gè)相互信任的關(guān)系網(wǎng)，這些關(guān)系對(duì)于項(xiàng)目的長(zhǎng)期成功至關(guān)重要。”

Rostedt 認(rèn)為，內(nèi)核開(kāi)發(fā)者的肩上承擔(dān)著比其他任何項(xiàng)目都要重的責(zé)任?！霸趦?nèi)核層，我們別無(wú)選擇，只能遵循這些做法。因?yàn)樗衅渌麘?yīng)用程序都在內(nèi)核之上運(yùn)行，內(nèi)核中的任何性能問(wèn)題或錯(cuò)誤都將導(dǎo)致上層的應(yīng)用程序出現(xiàn)性能問(wèn)題或錯(cuò)誤。我們必須完美處理內(nèi)核中的錯(cuò)誤，否則，整個(gè)計(jì)算機(jī)系統(tǒng)都將受到損害。我們非常關(guān)心每個(gè)錯(cuò)誤，因?yàn)閮?nèi)核中的錯(cuò)誤帶來(lái)的風(fēng)險(xiǎn)很高，這種思維方式也能讓我們很好地服務(wù)于任何軟件項(xiàng)目?！?/p>

上層的應(yīng)用程序會(huì)因?yàn)殄e(cuò)誤而崩潰，造成的后果可能是惹惱用戶，但風(fēng)險(xiǎn)不高。而內(nèi)核的錯(cuò)誤可能導(dǎo)致的后果是讓計(jì)算機(jī)上的一切都出現(xiàn)問(wèn)題，承擔(dān)著巨大的風(fēng)險(xiǎn)。

這就是 Linux 內(nèi)核開(kāi)發(fā)工作流程被視為軟件開(kāi)發(fā)行業(yè)黃金標(biāo)準(zhǔn)的原因。