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

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

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

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

開(kāi)源的價(jià)值觀

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

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

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

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

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

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

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

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

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

集中式管理

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

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

分布式管理

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

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

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

既然是分布式存儲(chǔ)，每個(gè)開(kāi)發(fā)者都有項(xiàng)目的完整備份，就不能像集中式管理那樣來(lái)玩數(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ì)該快照的引用。為了提高效率，如果文件沒(méi)有更改，Git 不會(huì)再次存儲(chǔ)該文件，只是指向它已經(jīng)存儲(chǔ)的先前相同文件的鏈接。Git 將其數(shù)據(jù)視為快照流（stream of snapshots）。這是 Git 和幾乎所有其他版本管理系統(tǒng)之間的一個(gè)重要區(qū)別。這種做法，讓每個(gè)開(kāi)發(fā)者都可以在本地有一個(gè)完整的項(xiàng)目備份。以至于絕大多數(shù)開(kāi)發(fā)者的操作都是本地的，因此這也是Git速度為什么如此超凡脫俗，碾壓對(duì)手的根本原因。

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

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

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

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

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

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

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

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

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

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

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

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

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

集中式開(kāi)發(fā)

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

分布式開(kāi)發(fā)

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

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

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

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

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