關(guān)聯(lián)回顧

我們?yōu)槭裁匆芯块_源？

開源，是先進(jìn)生產(chǎn)模式對(duì)傳統(tǒng)生產(chǎn)模式的超越

開源發(fā)展簡(jiǎn)史：從自由到開源，從開源到開放

開源的價(jià)值觀

全圖說開源軟件的發(fā)展歷史

2005年，Linus Torvalds開發(fā)Git這個(gè)開源的分布式代碼版本控制系統(tǒng)軟件的時(shí)候，他可能沒有意識(shí)到自己的開發(fā)會(huì)一統(tǒng)江湖。2022年的一份年度開發(fā)者調(diào)查問卷中，Git在開發(fā)者的使用率壓倒性地高達(dá)93.9%。那么Git是如何做到成功的呢？它到底有哪些特點(diǎn)是其他版本管理軟件沒有考慮到的呢？我們今天來談一下這個(gè)話題。

Git之所以是被極客Linus Torvalds 開發(fā)出來的，而不是被一個(gè)大公司開發(fā)出來的，因?yàn)樗麄兊拈_發(fā)模式有著根本理念的差別：集中式開發(fā)和分布式開發(fā)。

集中式開發(fā)：我一定要用你。你必須保證你的代碼是有用的。

分布式開發(fā)：我不Care你。你要說服我你的代碼是有用的。

集中式開發(fā)，不能容忍人力資源的浪費(fèi)，人員之間的關(guān)系也相對(duì)固化的，層級(jí)關(guān)系也是相對(duì)嚴(yán)格的。代碼責(zé)任路徑也是金字塔式的。集中式開發(fā)，一般發(fā)生在已經(jīng)有固定的雇員的項(xiàng)目團(tuán)隊(duì)。這些雇員是簽了雇傭合同的，是要領(lǐng)薪水的，是要占用項(xiàng)目的人力成本的，所以，他們必須要為項(xiàng)目創(chuàng)造價(jià)值，必須要有績(jī)效考核，每位開發(fā)者都不是混飯吃的，每位團(tuán)隊(duì)成員都有對(duì)應(yīng)的代碼責(zé)任田，每個(gè)人或者某幾個(gè)人為某幾個(gè)代碼文件或者文件目錄負(fù)責(zé)。

分布式開發(fā)，發(fā)生在開源項(xiàng)目里，基本是根據(jù)興趣和利益牽引而誘發(fā)的非穩(wěn)態(tài)合作。分布式合作之前，團(tuán)隊(duì)各方人員大多并未相識(shí)相知。所以這種開發(fā)構(gòu)建的前提就是項(xiàng)目創(chuàng)始人不認(rèn)識(shí)你，你要讓他（她）認(rèn)識(shí)你，你先主動(dòng)來找他（她），來證明你值得他（她）認(rèn)識(shí)和合作，如果你沒有說服他（她），僅僅是他（她）的粉絲，那他（她）自然也沒有什么問題，或者也能滿足其虛榮感：“你愿意拿我的代碼開啟自嗨模式，我不Care。”這種非穩(wěn)態(tài)的合作關(guān)系，必然允許人力資源的浪費(fèi)（而且，這也是開源項(xiàng)目的常態(tài)），也不太講究人員關(guān)系的固化，不存在所謂的雇傭關(guān)系。修改的代碼是否被別人接受由別人來決定。項(xiàng)目核心或者發(fā)起人自己來決定要去合并誰的代碼，而這種信任也是動(dòng)態(tài)變化的。

寫到這兒，我覺得這個(gè)和社交網(wǎng)絡(luò)（同樣是另外一種分布式網(wǎng)絡(luò)）的微博分享有些類似。Push在這里不那么重要，你可以分享發(fā)布微博（Push），但是沒有人關(guān)注你，沒有人給你小愛心，也就是自娛自樂而已。Pull貌似更重要，Pull的主動(dòng)權(quán)在對(duì)方手里，對(duì)方可以給你點(diǎn)贊，給你評(píng)論，甚至Follow你了，以后每次你發(fā)布什么都給你點(diǎn)贊，這樣你的分享才顯得更有意義。而轉(zhuǎn)發(fā)，可以類比為fork，如果在你的轉(zhuǎn)發(fā)上還有所修改，甚至有新的心得體會(huì)評(píng)論，這就相當(dāng)于在你的分支上修改。你覺得誰的評(píng)論寫的好，再轉(zhuǎn)發(fā)助推一次，又相當(dāng)于Pull，合入到了你的主分支。

由于這種基本理念和開發(fā)模式的本質(zhì)差別，導(dǎo)致代碼管理的方式，會(huì)產(chǎn)生極大的不同。

集中式管理

集中式管理，往往對(duì)代碼是當(dāng)作寶貴資源或者價(jià)值產(chǎn)出看待的。因?yàn)椴豢赡茉试S團(tuán)隊(duì)的開發(fā)者都擁有代碼。防賊防盜防程序員。項(xiàng)目時(shí)時(shí)刻刻防著這些開發(fā)者，也許哪一天解除了雇傭關(guān)系，他們離職了，跳槽了，是絕對(duì)不能讓他們把代碼帶離公司的。這是公司的寶貴代碼財(cái)富，必須要進(jìn)行各種安全管理。代碼倉，每位開發(fā)者，一般都是針對(duì)自己的代碼責(zé)任田范圍才有訪問和修改的權(quán)限，而對(duì)其他的代碼不允許看，不能改。這種權(quán)限設(shè)置一定是嚴(yán)格的文件級(jí)的安全權(quán)限管理體系。所以，代碼倉，一定是集中化管理的。

集中管理，就一定會(huì)使用服務(wù)器-客戶端的維護(hù)模式。服務(wù)器存放完整的代碼倉。而客戶端，僅存放開發(fā)者需要關(guān)注的責(zé)任田代碼。服務(wù)器一定要做到足夠的安全防護(hù)，還要考慮到容災(zāi)備份，因?yàn)橐坏┓?wù)器出現(xiàn)宕機(jī)或者擁塞，對(duì)整個(gè)團(tuán)隊(duì)的工作都會(huì)是全局的影響。而且，如果服務(wù)器的存儲(chǔ)考慮不周，真的出現(xiàn)了硬盤故障，導(dǎo)致代碼倉代碼丟失，那簡(jiǎn)直就是晴天霹靂。

分布式管理

分布式管理則不同，因?yàn)槭情_源項(xiàng)目，所以整個(gè)項(xiàng)目，凡是已經(jīng)在官方發(fā)布的項(xiàng)目代碼倉的內(nèi)容，所有人可以隨便看，隨便改，完全可以下載到本地，也就是每個(gè)人都有一個(gè)項(xiàng)目官方發(fā)布的完整備份。

可能有些人會(huì)抱怨Git的項(xiàng)目官方發(fā)布的代碼倉完整下載備份到本地會(huì)占用很大的存儲(chǔ)空間。這個(gè)其實(shí)不是開源項(xiàng)目的發(fā)起者所關(guān)心的。如果想玩開源項(xiàng)目，這點(diǎn)兒存儲(chǔ)空間的成本是非常低廉的。另外，這里還有一個(gè)非常重要的和集中式管理的數(shù)據(jù)備份策略問題。分布式存儲(chǔ)，會(huì)避免集中存儲(chǔ)引發(fā)的服務(wù)器宕機(jī)和硬盤損壞導(dǎo)致的重大數(shù)據(jù)丟失。分布式意味著每個(gè)開發(fā)者的電腦上都是一個(gè)數(shù)據(jù)“備份”節(jié)點(diǎn)。每個(gè)開發(fā)者本機(jī)不僅檢查文件的最新快照，還完整地映射了存儲(chǔ)庫，包括它的完整歷史。哪一天，項(xiàng)目發(fā)起者的主倉服務(wù)器發(fā)生了宕機(jī)或者硬盤損壞導(dǎo)致部分文件丟失，只需要向項(xiàng)目團(tuán)隊(duì)其他成員的電腦中讀取，就可以恢復(fù)對(duì)應(yīng)的代碼倉。

集中式管理的數(shù)據(jù)存儲(chǔ)

從概念上講，大多數(shù)代碼版本管理系統(tǒng)將信息存儲(chǔ)為基于文件的更改列表，比如：CVS、Subversion、Perforce、Bazaar 、SVN等。這些工具將它們存儲(chǔ)的信息視為一組文件以及隨時(shí)間對(duì)每個(gè)文件所做的更改進(jìn)行版本標(biāo)注（這通常被描述為基于增量的版本控制）。這種好處是對(duì)于每個(gè)版本的存儲(chǔ)都是增量存儲(chǔ)。當(dāng)然缺點(diǎn)也很明顯，就是很多存儲(chǔ)的版本都不是完整版本。不過反正數(shù)據(jù)都存在服務(wù)器，開發(fā)者也不會(huì)看到完整的版本，所以這個(gè)缺點(diǎn)對(duì)于集中式管理而言，也還說得過去。

分布式管理的數(shù)據(jù)存儲(chǔ)

既然是分布式存儲(chǔ)，每個(gè)開發(fā)者都有項(xiàng)目的完整備份，就不能像集中式管理那樣來玩數(shù)據(jù)存儲(chǔ)了。于是Git引入了快照（Snapshots）的概念。

Git 認(rèn)為項(xiàng)目的數(shù)據(jù)更像是微型文件系統(tǒng)的一系列快照。每次提交或保存項(xiàng)目狀態(tài)時(shí)，Git 基本上都會(huì)拍下當(dāng)時(shí)所有文件的樣子，并存儲(chǔ)對(duì)該快照的引用。為了提高效率，如果文件沒有更改，Git 不會(huì)再次存儲(chǔ)該文件，只是指向它已經(jīng)存儲(chǔ)的先前相同文件的鏈接。Git 將其數(shù)據(jù)視為快照流（stream of snapshots）。這是 Git 和幾乎所有其他版本管理系統(tǒng)之間的一個(gè)重要區(qū)別。這種做法，讓每個(gè)開發(fā)者都可以在本地有一個(gè)完整的項(xiàng)目備份。以至于絕大多數(shù)開發(fā)者的操作都是本地的，因此這也是Git速度為什么如此超凡脫俗，碾壓對(duì)手的根本原因。

集中式管理的代碼合并策略

集中式代碼管理的模式很簡(jiǎn)單，代碼保存在共享代碼倉里。你可以checkout代碼進(jìn)行修改，這個(gè)時(shí)候，代碼倉對(duì)應(yīng)的文件會(huì)打好標(biāo)記。對(duì)應(yīng)文件后面又有開發(fā)者想要進(jìn)行修改，他（她）就要進(jìn)入一種排隊(duì)機(jī)制。要等待你合并完之后，他（她）再更新，再修改合并。也就是一種串行機(jī)制。所以如果一個(gè)代碼責(zé)任田由多個(gè)人一同維護(hù)的話，他們之間就要做好某些事前約定，避免出現(xiàn)上述的尷尬情況，甚至出現(xiàn)不必要的代碼覆蓋。

分布式管理的代碼合并策略

分布式管理則不同，由于開源項(xiàng)目的每個(gè)開發(fā)者都有一個(gè)項(xiàng)目官方發(fā)布的完整備份。這種完整備份，會(huì)給開發(fā)者帶來幾個(gè)好處：

• 開發(fā)者會(huì)有機(jī)會(huì)了解到整個(gè)項(xiàng)目的全貌，或者至少可以了解到他（她）希望了解到一些關(guān)聯(lián)文件的源代碼到底是怎么寫的。

• 開發(fā)者會(huì)在本地離線工作，不必?fù)?dān)心沒有連上互聯(lián)網(wǎng)無法編輯或者commit提交代碼。這些工作都可以在本地完成。如果你在飛機(jī)上、或者網(wǎng)絡(luò)不是很好的環(huán)境、或者你人在你根本不信任的公共WiFi環(huán)境下，你想干活，你根本不用連上網(wǎng)，你就可以離線提交代碼，然后等你連上網(wǎng)，Git會(huì)幫你做上傳（Git做的這些都是后臺(tái)默默地干的，你不必關(guān)心）。

• 開發(fā)者可以在本地建立多個(gè)分支，隨便怎么折騰，不用去擔(dān)心對(duì)線上的主分支有什么影響。直到開發(fā)者有信心了，他（她）自己再?zèng)Q定是否同意這些分支被其他人看到或者被合并到的可能（push到自己的公共代碼倉）。

說到這兒，我不得不補(bǔ)充一下，為什么Linus Torvalds這么執(zhí)著地要求本地代碼倉地完備性，以及要離線工作。在2007年Google Talk上，Torvalds揭秘了他的動(dòng)因。因?yàn)檫@個(gè)哥們特別看中他編碼環(huán)境的安全性。他正在寫的代碼，是不希望給任何人看到的，為了保證安全性，這個(gè)服務(wù)器有3層防火墻，幾乎完全和互聯(lián)網(wǎng)隔絕。所以如果沒有本地完整備份，以及大部分操作都在本地完成的話，他在那種幾乎離線的狀況下貌似也干不了什么。

當(dāng)然，如果你的修改想要被官方接受，合入到主分支下一個(gè)版本發(fā)布，你可能要說服這個(gè)項(xiàng)目的集成管理員（Integration Manager），給他（她）寫一封長(zhǎng)長(zhǎng)的翔實(shí)郵件（至少是有說服力的），告訴他（她）你改的代碼有多牛逼，要求他（她）Pull你的修改。當(dāng)然，你也要做好心理準(zhǔn)備：集成管理員可能不鳥你：）因?yàn)樗ㄋ┯羞@個(gè)權(quán)力。

如果你足夠厲害（或者幸運(yùn)），反正被集成管理員看中了，他（她）會(huì)合入（merge）你的代碼到官方發(fā)布的代碼倉，并準(zhǔn)備下一次發(fā)布。我還是喜歡官方發(fā)布的代碼倉Git的英文名字：Blessed Repository，給這個(gè)代碼倉籠罩了一種神圣的光環(huán)：）在很多小項(xiàng)目中，集成管理員往往就是開源項(xiàng)目的發(fā)起人。每個(gè)項(xiàng)目發(fā)起人可能在合代碼的時(shí)候，心中也在默默地祈福：希望這個(gè)項(xiàng)目一定要成功哈：）

當(dāng)然，如果你的項(xiàng)目復(fù)雜度上升到一定程度，一個(gè)集成管理員已經(jīng)搞不定了，集成管理員就可以升級(jí)為司令員（Dictator）（編者注：我這里不能直接翻譯英文，但是大家也能從這些命名中看出Linus Torvalds這類極客經(jīng)常喜歡干的事情，就是自嘲。），他（她）把項(xiàng)目代碼倉進(jìn)行了拆分，比如按照某些子系統(tǒng)模式劃分子倉。這里司令員（也就是之前的集成管理員）在之前的工作中，應(yīng)該能發(fā)現(xiàn)某幾個(gè)開發(fā)者在某些領(lǐng)域有特長(zhǎng)（而他（她）也往往是根據(jù)這種觀察而劃分的子倉），他（她）就可以授權(quán)這些開發(fā)者負(fù)責(zé)某個(gè)子倉。這些開發(fā)者被稱為副官（Lieutenant）。所有的副官其實(shí)都是一個(gè)針對(duì)自己負(fù)責(zé)子代碼倉的集成管理員，按照小項(xiàng)目運(yùn)作的方式維護(hù)對(duì)應(yīng)子倉的master分支。他們也稱為仁慈的司令員（benevolent dictator）。最后司令員會(huì)把副官的master分支合并到自己的master分支，合并到官方發(fā)布的代碼倉（Blessed Repository）中去。

為了方便開發(fā)者的離線編程，Git還給開發(fā)者提供了一種暫存區(qū)（Staging area）的機(jī)制。這個(gè)暫存區(qū)給開發(fā)者一個(gè)再想一想的機(jī)會(huì)。也就是你的很多修改可以是先提交到暫存區(qū)里（git add）的，然后再一并提交到你的代碼倉（git commit）。這種機(jī)制很暖心，當(dāng)然，這個(gè)特性不應(yīng)該是分布式開發(fā)特有的，在集中式開發(fā)管理環(huán)境下，這個(gè)功能也可以開發(fā)出來。

集中式開發(fā)和分布式開發(fā)在開發(fā)者自由與約束方面，基本策略也有差別。

集中式開發(fā)

集中式開發(fā)是制定了非常多的規(guī)則，開發(fā)者只能在這些規(guī)則下進(jìn)行，甚至為了確保主分支的穩(wěn)定性，很多規(guī)則已經(jīng)脫離了版本管理系統(tǒng)本身，而是通過專業(yè)的項(xiàng)目經(jīng)理進(jìn)行額外的跟進(jìn)管理，比如提交前是否進(jìn)行了單元測(cè)試，集成測(cè)試，是否完整地運(yùn)行了測(cè)試套件，以及要寫各種文檔和報(bào)告，所有代碼必須有嚴(yán)謹(jǐn)?shù)拿?guī)范，注釋規(guī)范，提交步驟，甚至還得有一個(gè)故障庫關(guān)聯(lián)，讓開發(fā)者嚴(yán)格地自檢自查和修正。可以這么講吧，在集中式開發(fā)的規(guī)則下，開發(fā)者的自由是很少的，約束是很多的。總結(jié)一下，就是：規(guī)定你干的才能干，其他的都不能干！

分布式開發(fā)

分布式開發(fā)很少制定規(guī)則，有也是很少的規(guī)則，或者通過工具自動(dòng)支持和實(shí)現(xiàn)。一個(gè)明顯的規(guī)則就是開源項(xiàng)目必須得遵守開源許可證協(xié)議。目的是留給開發(fā)者最大程度的操作自由。當(dāng)然，在分布式開發(fā)的文化下，自驅(qū)力比被安排要重要得多，因?yàn)閳F(tuán)隊(duì)可以有很多開發(fā)者，多你一個(gè)不多，少你一個(gè)不少。你要想在團(tuán)隊(duì)中立足，或者有所建樹，就只能靠自己的打拼與貢獻(xiàn)，是否被集成管理者，副官或者項(xiàng)目發(fā)起人看中。當(dāng)然，由于互不相識(shí)，聯(lián)系方式單一，你們的這種從不信任到信任的過程建立在郵件溝通過程中一般是漫長(zhǎng)的，在項(xiàng)目開發(fā)過程中是需要不斷磨合的。當(dāng)然，如果某些開發(fā)者只是沖著學(xué)習(xí)的心態(tài)，看看代碼，膜拜一下大神，這也是開發(fā)者的自由。總結(jié)一下，就是：規(guī)定你不能干的別干，其他的都能干！

和Git同時(shí)代的有很多的版本管理系統(tǒng)，包括：SVN、CVS、Subversion、Perforce、Bazaar 、BitKeeper和Monotone。相比于其他的，BitKeeper和Monotone是去中心化的。今天上文談到的大部分Git的優(yōu)勢(shì)都是圍繞著集中化和分布式版本管理工具的比較，沒有去刻意比較BitKeeper和Monotone。

沒有使用BitKeeper，這里面有商業(yè)化的原因。當(dāng)時(shí)Torvalds確實(shí)動(dòng)過念頭想直接用BitKeeper，這是一個(gè)專用軟件，當(dāng)時(shí)采用的是 BitMover 許可證，不是真正開源的，所以包括GNU 項(xiàng)目創(chuàng)始人Richard Stallman在內(nèi)的一些人對(duì)使用BitKeeper表示了非常大的意見。甚至Linux 內(nèi)核郵件列表中還因此爆發(fā)了激烈的口水戰(zhàn)。Torvalds也是被逼無奈，自己直接開發(fā)了一個(gè)工具，還戲虐地稱為它Git（英式英語俚語“不愉快的人”），并直接把Git通過GNU 通用公共許可證 2.0 版（開源許可證）開源，這才有了后續(xù)的故事。這算不算是一種有心栽花花不開，無心插柳柳成蔭呢？就由大家來評(píng)判了。

當(dāng)然你可能也還要問，那他為啥也不想用Monotone呢？Monotone也是開源的，而且Monotone也使用 SHA-1來識(shí)別修訂并確保數(shù)據(jù)沒有因意外損壞而更改，看似沒什么大毛病啊？我們要理解Torvalds的性格，他是個(gè)追求完美的人。他對(duì)C++編寫的Monotone的性能表現(xiàn)不滿意，他認(rèn)為當(dāng)時(shí)的 Monotone 還沒有達(dá)到像 Linux 內(nèi)核開發(fā)這樣大的項(xiàng)目所需的性能水平，所以用C語言開發(fā)了Git。

最后談到Git能成功，Torvalds要感謝當(dāng)時(shí)在Google工作的濱野純（Junio C Hamano），他慧眼識(shí)珠，把Git的維護(hù)工作交給了這位日本軟件工程師牽頭，而濱野純也確實(shí)沒有讓他失望。Git后來在濱野純的領(lǐng)導(dǎo)下，聚攏了大量的開發(fā)者一同支持和共建，不斷地改進(jìn)和完善Git，至今已經(jīng)出了65個(gè)版本或補(bǔ)丁，讓它在保持簡(jiǎn)潔易懂的干凈界面前提下，豐富了更多的功能、插件和工具，成長(zhǎng)為當(dāng)之無愧的世界最優(yōu)秀的開源版本管理軟件。