簡介：?github是目前最火的開源軟件代碼托管平臺，那么Linux內核社區能否遷移到github上呢？Intel的Daniel Vetter寫了一篇關于這個問題的博客，他給出的答案是NO。至于這個答案是否公允，就留給讀者自己來判斷了。

本文主要根據?http://blog.ffwll.ch/2017/08/github-why-cant-host-the-kernel.html?做了摘要和改編而來。原作者Daniel Vetter是來自 Intel OTC 內核開發。

Daniel 說，這篇文章的寫作動機來自兩個事情：

其一是在 maintainerati 會議 (一個開源軟件維護者的業內聚會) 上的討論。 Daniel 和幾個開源軟件維護者討論了如何擴展真正的大規模開源項目，以及 Github 如何強制項目只能以幾種特定的方式來擴展。而 Linux 內核開發恰恰使用了不同的模型，這些正是在 Github 上搞開源的維護者不懂的，因此 Daniel 在討論中解釋 Linux 如何運作，以及 Linux 模型為何不同；

其二是在 Daniel 的另一篇博客 Maintainers Don’t Scale 的評論區里，支持最高的評論就是 “……為啥這些恐龍們不去使用現代的開發工具?“。(其實這個問題曾經在筆者心中也盤旋了很久….) 一些內核社區頂級的維護者，捍衛者傳統的郵件列表及布丁的提交方式，抵制使用 Github pull request 的方式。難道真的就是這一小撮掌權者的問題？Daniel 認為不是的。根本原因是，Github 的模式根本支撐不來 Linux 內核這種有著巨大體量的貢獻者的開發模式。因此，哪怕是把內核社區的幾個子系統移到 Github 上開發都是不可能的。Daniel 說，這不僅和托管 git 的數據有關，而且還和 how pull request, issue 和 fork 這幾個 Github 的功能的工作方式有關。(寫到這里，我有點兒懷疑這種結論，Github 那么多大型項目，托管整個社區也就罷了，說連個內核子系統都搞不定，就有點兒糊弄人了吧？)

Github 擴展的方式

Git 牛的地方就是讓每個人都可以很方便地 fork 開源項目，在其上創建分支。最后一但有了不錯的改進，又可以基于上游主倉庫創建一個 pull request，并且得到代碼的 review，測試，然后被合并。Github 也很牛，因為它把這些 Git 復雜的方式都用 UI 簡單化了，易學易用，讓新手很容易去為開源項目做貢獻。

最終，一個獲得巨大成功的開源項目，沒辦法在一個代碼倉庫里，能夠利用 tagging, labelling, sorting, bot-herding 和 automating 等手段管理好所有 pull request 和 issue，于是就必須通過把單一代碼庫拆分成多個可管理的部份組成。更重要的是，項目的各部分因為規模和成熟度的不同，需要不同的規則和流程：非常新的實驗性質的庫，與主線代碼相比，有不同的穩定性和 CI (持續集成) 條件。并且，或許項目里還有一大堆過時的，不會被支持的代碼，但是目前還不能刪除：這需要把非常大的項目拆分成多個子項目，每個子項目都有自己風格的流程，合并條件，獨立的倉庫，獨立的 pull request 和 issue 的跟蹤。一般來說，直到管理的開銷成為痛點，龐大的重組成為必要時，項目管理可能需要幾十甚至幾百全職的貢獻者。

幾乎所有的 Github 托管項目，解決這個問題時，都是靠把單一的源碼樹，按照功能區分，拆分成許多不同的項目。通常拆分的結果就是，一些核心代碼，加上一堆插件，庫，和擴展的代碼。所有這些通過某種插件或者安裝包管理器再構建到一起，在一些情況下，可能就是直接從其它的 Github 倉庫里直接拉取代碼構建。

因為幾乎所有的大項目都是這么搞的，在這里，Daniel 不再贅述它的好處，而是主要把這種做法的缺點指出來了，這里簡單摘要如下：

• 社區被不必要地割裂了。大多數貢獻者只有他們直接貢獻代碼的倉庫，忽略掉了項目的其它部份。這個對他們有好處，但是也會導致在不同的子項目里并行的，重復的工作被及時發現，并且共享成果。
• 項目重構和代碼共享存在導致低效的障礙：首先你需要為新代碼變更，發布核心項目的新版本，然后過一遍所有的其它子項目的代碼，然后更新它們，然后再去刪除核心項目里的舊的被共享的代碼。
• 理論上，支持多個子項目版本組合難以為繼。必須通過集成測試來保證。
• 對同屬一個大項目的多個子項目重組很痛苦，因為這需要重組 Git 倉庫和決定如何拆分。而在一個單一的代碼倉庫，重組僅僅是把維護者信息文件重新更新一下。

(看到這里，筆者認為，如果一個內部強耦合的代碼庫，非要因為規模大拆分，是存在這些問題…… 可是確實，項目如果足夠大，其實這種耦合關系就可以通過一些流程來規避了。例如，Linux 發行版，不就可以看作是按照上述方式拆分的多個倉庫的集合么？當然，Linux 發行版本來就是很多獨立開源項目組成的。但是筆者之前工作在 Solaris OS 上，其實就是把弱耦合的項目拆分成多個庫了。為了規避接口耦合的問題，才在不同的倉庫之間設計了接口穩定性上的約定，如公開接口，私有接口。對公開接口，要支持多版本，EOL 也會存在相應的規則。)

為什么要有 Pull Request？

Daniel 說，Linux 內核是他知道的幾個沒有像之前所說的那樣拆分的項目之一。Linux 內核是一個巨型項目，沒有子項目規劃的話，也沒辦法運轉。因此，看一下為什么 Git 需要 Pull Request 也是必要的：在 Github 上，Pull Request 是貢獻者的代碼得到合并的真正方式。但是，內核改動則是通過提交 patch 到郵件列表，甚至在 Git 被內核項目使用之后。

但在 Git 非常早期版本，Pull Request 就被支持了。最初的 Pull Request 的使用者，是內核維護者們，Git 早先就是為了解決 Linus Torvalds 的維護內核的問題的。毫無疑問，Pull Request 非常有必要，而且有用，但是，它不是為了處理獨立貢獻者的代碼改動的：直到今天，Pull Request 被用來轉發整個子系統的代碼變化，或者同步代碼的重構，或者橫跨多個子項目之間，同步交割代碼的改動。舉個例子，在 4.12 網絡子系統維護者 Dave S. Miller 的 Pull Request，被 Linus 提交: 這個提交里包含了兩千多的，來自 600 個獨立貢獻者的代碼提交，并且還有一堆代碼合并和來自下一級維護者的 pull request。但是，這里面所有的補丁，都是從郵件列表里挑選出來，由維護者提交，而不是由原作者提交。Linux 內核流程的古怪之處就是，原作者不提交代碼到代碼庫。這也是為啥 Git 獨立地跟蹤記錄提交者和作者。

Github 的創新和改進就包括了，到處使用 Pull Request，Pull Request 下放給了獨立貢獻者。但是，這并不是 Pull Request 最早被創造出來的目的。

Linux 內核擴展的方式

初看 Linux 就是一個單體的倉庫，所有東西都被塞進 Linus 的主倉庫。但是實際上相差甚遠：

• 用 Linus Torvalds 主倉庫運行 Linux 的人很少。如果他們運行 upstream 內核，通常都是用穩定內核分支。但更多的是用 Linux 發行版，這些發行版通常會有額外的補丁和 backport，并且甚至不是 kernel.org 托管的，而通常會是完全不同的組織。或者，他們用硬件制造商那里拿到的內核，與主倉庫相比，這里常常有非常多的改動。
• 除了 Linus 自己，沒有人直接在 Linus 的倉庫里做開發。每個子系統，甚至是大的驅動，有它們自己的 Git 代碼庫，及自己的郵件列表去跟蹤補丁提交和問題討論，這些子系統都是相互獨立的。
• 跨子系統的工作，是在 linux-next 的集成代碼樹里做的，它通常包含了上百個 Git 分支，這些分支來自不同的 Git 代碼庫。
• 所有的這些都通過 MAINTAINERS 的文件和 get_maintainers.pl 的腳本來管理，它可以告訴任意給定的代碼片段相關的一切，誰是維護者，誰是代碼 review 者，哪里是 Git 倉庫，使用哪個郵件列表，哪里去報告 bug。這個工具不僅僅是根據文件的位置，也通過捕捉代碼的一些特征來確定跨子系統的改動，例如，設備樹的處理，kobject 的層級結構，都會被合適的專家處理。

Daniel 認為，這種方式有有如下好處 （自然是和前面 Github 上的子項目拆分相比的)，摘要如下：

• 重新組織子項目的拆分超級得容易，只需要更新 MAINTAINERS 文件，隨后創建新的 Git 倉庫就可以了。
• 跨子系統的 Pull Request 討論和問題的討論，非常非常容易在子項目之間重新分派，只需在郵件回復里增加要 Cc: 的子系統的郵件列表。類似地，做跨子系統的工作，也會非常容易的協同，因為同一個 Pull Request 可以被提交到多個子項目，并且只有一個全局的討論。
• 跨子系統的工作，不需要多項目之間任何發布的協同。直接在自己的倉庫里修改全部代碼即可。
• 它也不妨礙你創建自己的實驗性改動，這是多倉庫重要好處之一。直接在自己的 fork 里增加代碼就好，沒有人強迫你把代碼改回去，或者把你的代碼放到單一的倉庫，因為沒有中心倉庫。

(說了這么多，Github 唯一的問題就是不支持跨倉庫的工作流唄….

Linux 的模式： monotree with multiple repositories

有人可能會質疑，Linux 的模式看起來像是一個，本文開頭說過的，有擴展問題的單體代碼庫。接下來，Daniel 在文章中，花了很多篇幅解釋了，Linux 其實是 單體代碼樹，多個代碼倉庫 (monotree with multiple repositories) 的模式。

Daniel 還以內核社區的維護者們之間的 Pull Request 工作流為例，說明 Linux 這種模式在 Github 里為啥不行，摘要如下：

簡單的場景就是在內核維護者的層級結構中擴散代碼改動，直到改動最終落地到了可以最終做軟件發布的代碼樹里。對 Github 來說，這個很容易，直接用 Pull Request UI 就可以做到。

更有意思的是，跨越多個子系統的改動，因為 Pull Request 的工作流會成為一個無環圖及其變體組成的 Mesh 網格。第一步是讓代碼改動都被所有子系統的維護者 Review 和測試。在 Github 工作流里，這個將是一個 Pull Request 同時提交到多個代碼庫，只要有一個單一的討論線索，并在所有的倉庫里共享。在內核社區里，這個是靠補丁同時提交給一大堆郵件列表和維護者來實現的。

內核這種 Review 方式，通常還不是代碼最終合并的方式。而是在所有其它子系統維護者同意的情況下，多個子系統其中的一個被確定為接受 Pull Request 的方式。通常，被選的子系統是受到改動影響最多的子系統，但是有時候，也可以是因為某個子系統正在做的工作與這個 Pull Request 有沖突。有時候，還可以是一個全新的代碼倉庫和其維護者被確立。這通常發生在改動的功能跨越了整個代碼樹，不是很容易地在一個地方，一個目錄下的被一些文件囊括的情形。最新的例子就是 DMA mapping tree (DMA 映射項目的代碼樹)，該項目試圖將各種驅動，平臺維護者，還有處理器架構支持的改動都在一個項目里完成。

但是，有時候，多個子系統的代碼改動存在沖突的情況，導致它們都需要不小的努力去解決合并沖突。在這種情況下，這種跨子系統的補丁，通常不能直接被接受 (相當于一個 Github 上的 rebase 的 Pull Request)，而是 Pull Request 經過修改，使這些補丁對所有子系統都通用，然后再合并到所有子系統。為了避免無關的改動影響到某個子系統，共同的基線是非常重要的。由于這種 Pull Request 是為了一個特定的 Topic 而存在的，這些代碼分支也通常被叫做 Topic 分支。

Daniel 還舉了微軟公司的 OS 項目的例子，說它是一個單體代碼樹。并且根據他和微軟的人交流，這個代碼樹大到需要微軟寫一個 GVFS 的虛擬文件系統來支持更高效的開發。（筆者認為，這個例子略有些不恰當，微軟的 OS 不光有內核，還有用戶態的許多其它代碼，而這里的內核代碼樹就是內核代碼，從更全局和更平等的 Linux 發行版的角度看，Linux 發行版其實是多個代碼樹了…….. 恰恰是 Daniel 在前面抨擊 Github 上用多代碼樹劃分子項目的方法……）

親愛的 Github，輪到你了…

很不幸的是，Github 不能支持前面討論的跨子系統的工作流，至少在原生的 UI 是不能的。當然，這些工作可以用原始的 git 命令完成，但是不得不回到通過郵件列表發 patch 的方式，Pull Request 也得回到郵件，然后手工合并。在 Daniel 看來，這是唯一的原因，為什么 kernel 社區不能搬到 github 上。也還有一些小問題 (真的是小問題么?)，一些頂級的維護者對 Github 極度地反對，但這個不是一個技術問題。并且，不只是 Linux 內核，它是所有巨型的 Github 項目要擴展所面對的一般問題，因為 Github 沒有給他們一個擴展到多個倉庫，但是保持一個單體代碼樹的選擇。

簡而言之，Daniel 提出了一個他認為簡單的新特性需求給 Github：

請支持 Pull Request 和 issue 跟蹤管理跨多個不同的，基于單體代碼樹的代碼倉庫。

非常簡單的想法，但是有巨大的影響。

Daniel 不但給出了核心想法，還給出了一些建議的細節，摘要如下：

倉庫和組織

首先，需要支持同一個組織可以擁有同一個代碼庫的多個派生倉庫。以 git.kernel.org 為例，上面大多數代碼庫不是個人的。

在一個代碼庫里使用多個分支不能替代這個需求，因為之所以要拆分代碼庫，主要就是想讓 Pull Request 和 issue 彼此隔離。

還有就是，需要可以基于既成事實(歷史)去建立代碼庫派生關系。對新項目來說，這個不是問題。但以 Linux 搬遷為例，這是個問題：一次要把 Linux 所有子系統都搬過來，并且，Github 上已經存在大量的 Linux 代碼庫，彼此間沒有正確的 Github 派生關系。

Pull Request

Pull Request 需要能同時提交到多個代碼庫，但是還可以保一個討論線索。一次提交給所有代碼庫以外，還要能夠重新指派 Pull Request 到某個代碼庫的不同分支。

并且，Pull Request 的狀態需要因每個代碼庫而不同。一個代碼庫的維護者或許關閉了這個 Pull Request 而不去合并，因為維護者們一致同意其中一個子系統拉取這個 Pull Request，而那個維護者將會合并和關閉 Pull Request。另一個代碼樹或許要按照無效的請求去關閉這個 Pull Request，因為這個 Pull Request 不適合這個舊版本的代碼庫，或者某個特定廠商的派生代碼庫。甚至更有意思的是，一個 Pull Request 或許會被合并很多次，在每個子系統的代碼庫里，且使用不同的合并提交 (Commit ID)。

Issues

和 Pull Request 類似，問題跟蹤也需要按照多個代碼庫隔離，且需要有移動的能力。一個例子就是，一個 bug 可能先報告給了一個發行版的內核代碼倉庫，然后經過 bug 分析，這個驅動的 bug 也在最新的開發分支存在，因此這個 issue 不但和這個代碼庫有關，還需加上主線 upstream 分支，或許更多的代碼倉庫。

Issue 狀態應該在不同代碼庫獨立，因為一次在一個倉庫的 push，不會理解在所有的倉庫可用。甚至，backport 到老內核和發行版，可能需要更多的工作，而一些代碼庫可以決定不值得修這個 bug，以 WONTFIX 關閉這個 bug，但是同時在其它代碼庫里它標識為成功解決。(筆者之前的公司，這些功能都有啊。的確這是一個商業軟件的缺陷跟蹤系統必須有的功能)

總結: 單體代碼樹，不是單體代碼庫 (Monotree, not Monorepo)

Linux 內核沒打算搬到 Github 上去。但是在 Github 上支持搬遷“單體代碼樹，不是單體代碼庫”這種類型的項目到 Github 上，將會是對所有存量的巨型項目非常大的好處。

Tradeoff 無處不在

Daniel 的文章到此為止，接下來是筆者談一談自己的看法，一家之言，僅供參考。

首先，因為 Github 的設計問題，把緊耦合的代碼庫強行拆分成多個子項目確實是一個大問題。但是，對原本就是松耦合的代碼之間，拆分的好處也是明顯的。大家可以按照各自的方向，節奏，去開發和維護。廣義的看，Glibc 和 Linux 內核的關系就是這樣，之所以運轉良好，穩定的系統調用接口是關鍵。因此，代碼庫的劃分邊界應該以是否存在穩定的協議和接口為前提。

其次, Github 作為世界上最大的同性社交平臺, 解決的是個體開源程序愛好者的需求問題。因此，在管理模型上，Github 不支持“單體代碼樹，不是單體代碼庫” 這種大型開源項目需要的模式也不奇怪。作為產品的定位來說，或許當前 Github 的設計，正是它成功的一個原因。正是它才讓 Git 從少數 Linux 內核開發者手里迅速傳播到整個程序員群體。

最后，以 KISS (keep it simple stupid) 的原則看，對主流用戶足夠傻瓜化，是 Github 的最大優勢。但隨著 Github 的影響越來越大，越來越多的企業和組織開始在其上托管項目，或許 Daniel 的建議值得認真考慮？至少，企業用戶才有可能付出真金白銀呢。

看來，不單在技術上我們面臨各種 tradeoff，在產品的發展方向上，也是一樣的。誰知道這篇文章所詬病的 Github 的缺點，不是當初 Github 產品經理的深度思考后的決定呢？而 Daniel 的建議，說不定又是新形勢下滿足大企業需求的一個需要呢？

原文鏈接
本文為阿里云原創內容，未經允許不得轉載。?

總結

以上是生活随笔為你收集整理的Linux内核社区迁移到github?的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。