Linus Torvalds 如何協調大型開放原始碼系統？Linux、Git 與分散式協作

Linus Torvalds 是 Linux kernel 的發起者與 Git 作者；他把大型開源協作拆成分散式版本控制、維護者信任鏈與週期化合併流程。

1991 年他開始開發 Linux kernel，2005 年 BitKeeper 使用關係中止後建立 Git。下文會把可查的歷史，和本文對工程影響的綜合判讀分開說明。

增量補充：大型開源系統靠維護鏈維持可合併

Linux kernel 的開發文件說明，子系統維護者各自管理程式樹，主線合併則有清楚的責任鏈；這能支持本文把 Linus 的影響理解為協作流程與信任邊界，而不只是「一個人寫了 Linux」。來源：Linux kernel documentation — How the development process works。

評估大型開源專案時，除了看提交量，也要看誰能審查、誰能合併、版本如何回溯、破壞性變更如何公告，以及新貢獻者如何進入流程。分散式協作不是沒有中心，而是把中心決策、子系統責任與可追蹤的變更路徑分開。

先看 5 個重點

• Linux kernel 是核心；一般人所說的 Linux 作業系統，通常還包含發行版、工具鏈、桌面或伺服器軟體。
• Git 的直接背景是 2005 年 BitKeeper 不再提供 Linux 社群免費使用；新工具必須支援高速、非線性開發、分散式工作與大型專案。
• Linux kernel 的 patch 不會直接從作者進入 mainline，而是先經郵件列表、子系統維護者、測試樹與上游整合。
• Linus 擁有 mainline 的最終合併位置，但不等於親自審查每一個 patch。
• Git 與 Linux 的共同點，不只是「都是 Linus 做的」，而是兩者都把協作邊界、歷史與信任關係變成工具可處理的資料。

Linux kernel 與 Linux 作業系統有什麼關係？

Linux 官方 Git 書記錄，Linus 在 1991 年開始 Linux kernel；早期維護以 patch 與封存檔案交換變更，後來才演變成更完整的版本控制工作流。這些歷史節點可在 Pro Git 的 Git 歷史交叉確認。

kernel 是作業系統的核心，不等於一般人下載的完整「Linux 作業系統」。後者通常還包含驅動、使用者空間工具、套件管理、桌面或伺服器軟體，以及發行版的整合。Linus 啟動的是 kernel；完整生態則由全球開發者、子系統維護者、測試者與發行版團隊長期共同建立。

這裡要先釐清一個常見誤解：Linus 不是「一個人完成 Linux」。比較準確的說法是，他建立了最初的 kernel、持續維護 mainline 的整合入口，並參與治理規則；Linux 的功能與穩定性則來自長期累積的全球開發者、子系統維護者、測試者與發行版團隊。

Linux kernel 如何處理大型協作？

Linux kernel 官方的 開發流程文件把流程拆成幾層。開發者先把 patch（變更補丁）發到相關 mailing list（郵件列表），社群進行初步與廣泛審查；之後由子系統 maintainer（維護者）接受，放進自己的 tree 和 linux-next 等測試路徑。只有在變更經過這些過濾後，才可能由上游 maintainer 請 Linus 合併到 mainline（主線）。

這是一個 chain of trust：每一層維護者對自己管理的範圍負責，也把變更的作者、背景與測試狀態一併往上游傳遞。文件特別提醒，直接把 patch 寄給 Linus 通常不是正確路徑；找到負責該子系統的人，才是進入 kernel 的第一步。這個規則把「誰能判斷這個變更」和「誰擁有最終整合權」分開。

開發週期也有清楚節奏。merge window（合併窗口）開啟時，已經被收集、測試、分層整理的主要變更進入 mainline；官方文件描述它通常約兩週後關閉，第一個 release candidate（候選版本）開始，接下來數週主要處理 bug fix 與穩定性。這種節奏讓新功能與修錯不會在同一個階段無限混合。

Git 為什麼在 2005 年出現？

Git 官方書記錄，Linux kernel 在 2002 年開始使用 BitKeeper；2005 年使用關係中止後，Linux 社群因此需要自己的版本控制工具。當時的需求不是做一個漂亮的檔案同步器，而是同時滿足幾個相互牽制的條件：速度快、設計簡單、能處理大量平行分支、完全分散式，並且能承受 Linux kernel 的資料量。這些條件與時間點見 Pro Git 的 Git 歷史。

Linux Foundation 的 Linus 訪談補充了另一個角度：分散式版本控制讓每個人都能擁有自己的 repository，減少「誰有中央寫入權限」所造成的政治與流程摩擦。Git 的 branch、merge 與完整歷史因此不是單純的工程便利，而是讓協作者能先在自己的環境驗證、再以可追溯方式提出整合。

Linux 與 Git 的連接，不是英雄故事而是工作流

Git 是為 Linux kernel 的工作方式而生，但它沒有把 kernel 的全部治理自動化。工具能保存提交、分支、作者與合併歷史，不能替團隊判斷一個 patch 是否符合架構、是否破壞相容性、是否有足夠測試。Linux 的維護者層級與 Git 的資料模型互相支援：前者決定誰先審，後者讓變更可以被比較、重播與追蹤。

這也是為什麼 Git 後來被大量非 Linux 專案採用。它提供的是一組通用的協作原語；不同專案仍要自己建立 review、CI、release、責任邊界與安全政策。把 Git 等同「用了就自動得到開源治理」，會誤讀它的能力。

常見誤讀與限制

第一，Linux kernel 的最終 merge 權集中在 Linus，不代表每個技術判斷都由他獨自完成。官方文件用 maintainer、subsystem tree、-next 和 chain of trust 描述的，正是一套分層決策。

第二，Git 並不是所有團隊都必須採用的唯一版本控制方式。它的分散式與非線性能力對大型協作很有價值，但團隊仍要考量學習成本、權限模型、合併策略、資料敏感度與部署流程。

第三，Linus 的個人溝通風格不能代替 Linux 的正式流程。Linux kernel 已有公開的 Code of Conduct；研究治理時，應分開討論個人言行、社群規範與技術維護機制。

Linus Torvalds 的工程遺產是什麼？

本文的工程判讀是：Linus 的可借用遺產不只在兩個工具，而在把大型軟體的協作問題拆成可追蹤的變更、分層的責任、可回溯的歷史與週期化的整合。這些做法不會自動消除衝突，也不能取代測試與判斷，但能讓一個超過單一團隊記憶範圍的系統，仍然保持可維護。

官方資料與延伸閱讀

• Git Project：A Short History of Git
• Linux kernel：How the development process works
• Linux Foundation：10 Years of Git — An Interview with Linus Torvalds
• Linux kernel：Code of Conduct

增量分析：大型開源專案的難題，是讓快速提交仍能維持可整合的秩序

Linus Torvalds 的影響可從維護流程看，而不只看創始故事。Linux 核心需要分支、審查、合併、版本、測試和子系統維護者協作；Git 則把分散式工作、歷史追蹤與衝突處理做成工具。真正的規模化，來自責任邊界與可追溯流程，而不是任何單一人的全天候控制。

開放原始碼也有代價：新貢獻者需要學習社群規則，維護者承擔審查壓力，技術債可能被大量使用者放大。評估 Linux 或 Git 的遺產時，應把程式碼、工具、治理與全球貢獻網絡一起看，並把個人風格與專案制度分開；這樣才能解釋系統為何能在創始者之外持續演進。