4 月 7 日，全球最主流的版本控制系統(tǒng) —— Git迎來15 周年紀(jì)念日，項目主要維護(hù)者 Junio C Hamano（濱野純） 先生發(fā)郵件慶祝了這一日子。

　　我們知道，所有的軟件項目在整個生命周期中都要經(jīng)過不斷迭代，在一個又一個的新版本中完善自己的功能。開源項目更是如此，一個健康的開源項目，在“集市”模式下接受來自世界各地開發(fā)者提交的代碼 ，版本更新頻率通常更高。如何管理項目的版本更新，是項目開發(fā)、維護(hù)過程中必須考慮的問題。

　　什么是版本控制工具

　　在開始我們的故事之前，首先讓我們來認(rèn)識一下版本控制工具。版本控制的核心述求是歷史紀(jì)錄查詢和實現(xiàn)協(xié)同開發(fā)。以開源項目來說，在多人協(xié)作開發(fā)的模式下，每個人都向服務(wù)器提交自己的文件，就可能存在著代碼被多次修改、替換的風(fēng)險，但是版本控制能夠在每次更新操作后進(jìn)行相應(yīng)的記錄。一旦發(fā)生誤操作，開發(fā)者能夠根據(jù)服務(wù)器中的版本記錄，將項目恢復(fù)到出現(xiàn)問題之前的其他版本。因此，借助版本控制技術(shù)，軟件開發(fā)項目可以被分割為若干模塊，每個模塊并行地進(jìn)行開發(fā)工作，從而有效地提高了整體編程效率。

　　主流的版本控制工具主要分為兩種，即集中式與分布式。

　　集中式版本控制工具類似網(wǎng)吧的管理系統(tǒng)，所有項目的歷史文件與版本信息都存放在服務(wù)器上，而客戶端就只能保存當(dāng)前的狀態(tài)信息。這種所有雞蛋裝在一個籃子里的模式缺點(diǎn)非常明顯，一旦服務(wù)器損壞，項目所有的歷史數(shù)據(jù)就會丟失，因此需要大規(guī)模的安全備份。比較有代表性的集中式版本控制工具有 SVN、VSS、CVS 等。

　　分布式版本控制工具最大的特性就是任意客戶端之間可以互聯(lián)，當(dāng)然也包括服務(wù)器。這樣一來，開發(fā)者的客戶端本地也存有項目完整的歷史記錄，當(dāng)有一個客戶端損壞時，可以從另一個沒有被損壞的客戶端中提取歷史數(shù)據(jù)，恢復(fù)之前的狀態(tài)。在協(xié)同開發(fā)時，各個客戶端之間可以很好地同步開發(fā)進(jìn)度，避免出現(xiàn)重復(fù)提交等問題。

　　毫無疑問，分布式版本控制工具擁有更為先進(jìn)的理念，其誕生的過程也是得益于網(wǎng)絡(luò)通信技術(shù)的普及與開源社區(qū)的蓬勃發(fā)展。

　　天才的幫手

　　我們的故事始于 1991 年，大名鼎鼎的開源項目 Linux 問世，作者 Linus Torvalds 一躍成為 IT 界的大明星，被人們稱為天才。由于當(dāng)時 Linux 社區(qū)仍采用傳統(tǒng)的集中式版本管理，開發(fā)者提交的 patch 都匯集到 Linus 這里，讓他肩上的擔(dān)子很重。

　　（ Linus Torvalds ）

　　在項目早期，Linus 以最原始的人力來完成 Linux 版本管理工作，包括逐條細(xì)看每個 patch、手動合并開發(fā)者提交的代碼、更新版本歷史信息等。由于這段“痛苦”的經(jīng)歷，Linus 本人曾多次公開吐槽 “代碼管理是計算機(jī)領(lǐng)域最無趣的事”……

　　然而隨著社區(qū)的逐漸壯大，Linux 的系統(tǒng)變得越來越龐大，代碼越來越繁雜，繼續(xù)依靠手動合并代碼顯然已經(jīng)不太現(xiàn)實。

　　1999 年，一家名為 BitMover 的公司發(fā)布了一款收費(fèi)的分布式版本控制軟件 BitKeeper ，BitMover 的 CEO Larry 給 Linux 社區(qū)特別提供了一個可以免費(fèi)使用的版本，期望 BitKeeper 能幫助 Linus 免于陷入不斷加重的 Linux 內(nèi)核管理工作中，但條件是不能破解這款產(chǎn)品。

　　Linus 在使用 BitKeeper 之后不久就愛上了它，直言其是“ Best tool for the job ”。BitKeeper 讓每個開發(fā)者都擁有自己的主副本（ master copy ），完整的副本意味著可以在本地做所有事，而不是所有的 patch 只能提交到服務(wù)器（Linus）這里。于是，Linus 可以把一些 patch 的審查工作交給 Liunx 子系統(tǒng)的維護(hù)者們，對于比較值得信任的維護(hù)者甚至不需要他自己再審查一遍，而他只需要對一些自己不太信任的維護(hù)者 “重點(diǎn)關(guān)照” 即可。2002 年，Linux 內(nèi)核主線代碼就全面開始使用 BitKeeper。

　　盡管 BitKeeper 的出現(xiàn)賦予了 Linux 社區(qū)更好的協(xié)同開發(fā)能力，讓 Linux 內(nèi)核的開發(fā)效率成倍提高，但其閉源的特性仍然讓 Linus 在開源界遭到了一些非議。開源泰斗 RSM 就嚴(yán)厲批評 Linus 不該使用一款非自由的軟件來管理世界上最大的開源項目。這些負(fù)面的聲音也為之后 Linux 與 BitKeeper 的分道揚(yáng)鑣埋下了伏筆。

　　分道揚(yáng)鑣

　　事實證明，指望一個全球最活躍的開源社區(qū)長期使用一個閉源工具似乎不太切合實際，畢竟這里聚集了一批全世界最有能力的程序員。于是，社區(qū)內(nèi)開始出現(xiàn)“需要一個類 BitKeeper 的開源工具”的聲音，甚至有實干者已經(jīng)開始著手實現(xiàn)這件事情。

　　2005 年，Linus 本人所屬公司 OSDL 的老板 Andrew Morton 資助的一個項目組開始對 BitKeeper 協(xié)議進(jìn)行反向編譯，試圖破解 BitKeeper 以創(chuàng)造出一個類似的開源工具。BitMover 公司很快發(fā)現(xiàn)了這一動作，Larry 表示這破壞了免費(fèi)版 BitKeeper 的許可協(xié)議，盡管這件事或許與 Linus 本人無關(guān)，但確實嚴(yán)重影響了公司的利益，他們最終決定逐步停止對免費(fèi)版 BitKeeper 的支持，但會給 Linux 進(jìn)行工具迭代的時間。

　　這樣的矛盾在早期的商業(yè)公司與開源社區(qū)之間十分常見，由于此時與開源項目相關(guān)的商業(yè)模式并不成熟，很多像 BitMover 一樣的商業(yè)軟件公司選擇站在開源社區(qū)的對立面，以保護(hù)自己賴以生存的傳統(tǒng)商業(yè)模式。這些軟件公司被業(yè)內(nèi)稱為保守派，尤其是以微軟、Oracle、SAP 等為首的大型軟件開發(fā)商，他們堅持以付費(fèi)的原則提供專有企業(yè)軟件，憑借產(chǎn)品的技術(shù)壁壘收取高額的許可費(fèi)。這樣的商業(yè)模式不僅被追求開放自由的開源社區(qū)所唾棄，高昂的軟件采購成本也讓很多企業(yè)的 IT 采購人員頭疼不已。

　　不過，BitMover 的做法在當(dāng)時來看確實也無可厚非，他們正當(dāng)?shù)鼐S護(hù)了自己的合法權(quán)利，挽回了因產(chǎn)品被破解可能帶來的經(jīng)濟(jì)損失。但令他們?nèi)f萬沒有想到的是，開源社區(qū)強(qiáng)大的生產(chǎn)力可以成為他們發(fā)展的沃土，也能成為毀滅他們的武器。

　　用開源的方式創(chuàng)造 Git

　　失去 BitKeeper 意味著 Linux 需要重新尋找一個分布式版本控制系統(tǒng)，Linus 考察了當(dāng)時所有的系統(tǒng)，卻沒有一個能夠讓他滿意。

　　“ 于是他在郵件列表里發(fā)了一封郵件，說自己寫了一些代碼，準(zhǔn)備作為在找到更好的版本管理系統(tǒng)之前的過渡系統(tǒng)。我覺得這似乎是件挺有意思的事情，于是就把代碼下載了下來，看了一下發(fā)現(xiàn)只有 1244 行。” 這是目前 Git 的主要維護(hù)者、Google 工程師 Junio C Hamano（濱野純）在一次采訪中的描述。

　　是的，天才 Linus 只花了 10 天的時間，用 C 語言寫了 1244 行代碼，這就是如今火遍全球的分布式版本控制系統(tǒng) Git 的雛形。Linus 把寫好的代碼發(fā)到 Linux 社區(qū)的郵件列表里，并邀請社區(qū)里的開發(fā)者一起來完善它。“ 在一周時間內(nèi)發(fā)生了很多事，不過歸納起來就是 Linux 的內(nèi)核開發(fā)者們聽說 Linus 要用個‘新玩意’來管理代碼，如果那個‘新玩意’太難用的話大家都痛苦，還不如一起想辦法把這個東西做好用點(diǎn)。” Hamano 就是收到郵件并首批參與 Git 項目的開發(fā)者之一。

　　據(jù) Hamano 回憶，當(dāng)時 Linus 考察了市面上所有的版本控制系統(tǒng)，沒有一款讓他滿意的原因是它們都沒有代碼合并（merge）功能。 “ 因為 Linus 只寫 C 和 Shell，而 merge 的邏輯實在太復(fù)雜，所以他多次發(fā)郵件到郵件列表，說要是有人能夠用腳本語言實現(xiàn)一個就好了。不過誰也沒有上鉤。就這么過了一個星期，一直關(guān)注郵件列表的我用 Perl 把 Linus 過去多次提到的 merge 算法實現(xiàn)并投到了郵件列表里。這是我第一次有一定規(guī)模地向開源項目貢獻(xiàn)代碼。然而，盡管我詳細(xì)地寫了將近 30 個測試用例以及各種分支條件下應(yīng)該怎么處理的表格，6 個小時以后 Linus 提交到 master 分支的卻是個截然不同的東西。據(jù)本人說是想到了更好的辦法所以就這么著了。”

　　雖然聽起來有些任性，但 Linus 給出的新方案確實讓 Hamano 折服。

　　對于 merge 功能，BitKeeper 的做法是在 work tree 里基本上只存放自己的文件，而 merge 不發(fā)生在這里。merge 時首先會創(chuàng)建一個臨時文件夾，在里面展開 merge 結(jié)果，發(fā)生沖突時就在里面解決，然后提交 commit 并在 work tree 里展開，這樣就算 merge 完成了。這個方法很好地解決了協(xié)同開發(fā)常常遇到的代碼沖突問題。類似于把發(fā)生沖突的兩人關(guān)進(jìn)一個小黑屋，“決出勝負(fù)”后的勝利者再進(jìn)入 work tree 。

　　而 Linus 決定取消這個臨時文件夾，直接在 work tree 上 merge 。具體來說，就是每次提交 commit 之前會生成記錄本次提交內(nèi)容的 index，而這個 index 遵循“三步合并”原則，比如我們有一個共同的版本，你在這個版本的基礎(chǔ)上做了一些變更，我在這個版本的基礎(chǔ)上做了另一些變更，然后將這兩個差分 merge 起來。那么把原始版本、我修改的版本、你修改的版本分別作為 stage1，stage2，stage3 依次添加到 index 里，merge 就算完成了。例如最簡單的情況，我和你都沒有做出變更，那么 merge 的結(jié)果就是沒有變更。如果我做了變更而你沒有，那么最后得到的就是我變更以后的代碼，反之亦然。另外還有一種特殊的情況，就是你和我都做了“相同”的變更。

　　開源本質(zhì)上就是大家一起做一個項目，互相 merge 的過程。Git 就是在這樣的模式下誕生并日趨完善，成長為全球最主流的開源版本控制系統(tǒng)。而 Linus 做的事情只是花 10 天時間寫了 1244 行代碼，然后審查大家提交的 patch 。“雖然最早是我做了全部的編碼和設(shè)計，但之后的維護(hù)都由 Hamano 來做，他把 Git 做得更接地氣，讓所有人都能使用。” Linus 曾在 Google 進(jìn)行的一次演講中毫不吝嗇地夸贊了自己的伙伴。

　　（圖右為 Junio C Hamano）

　　作為開源項目的管理者，Linus 不僅是個智商超群的編程天才，他的管理情商也很高。在維護(hù)一個開源項目時，對別人說“No”是家常便飯。當(dāng) Linus 拒絕別人的 commit 時，他總會在回復(fù)中強(qiáng)調(diào)“拒絕這個 commit 不是因為你的能力不行，而是這個 commit 不合適”，同時還會指出 commit 中的亮點(diǎn)并給予肯定，讓對方覺得自己的工作沒有白費(fèi)，這樣就不會打擊貢獻(xiàn)者的熱情。“ 我那時候也是，Linus 對我說，雖然你的提交沒有采用，但測試用例還是能用的，針對現(xiàn)在的實現(xiàn)你稍微修正一下吧。” Hamano 回憶說。

　　在 Hamano 等人的協(xié)助下，Git 誕生近一個月后，Linux 系統(tǒng)的源碼就全部改用 Git 進(jìn)行版本管理，而其他的開源項目社區(qū)也如獲至寶，Git 的名氣很快就在開源界傳播開來。

　　截然不同的命運(yùn)

　　2008 年，基于 Git 實現(xiàn)的代碼托管平臺 GitHub 面世，從此 Git 更是享譽(yù)全球。有意思的是，GitHub 當(dāng)初并不是由 Git 社區(qū)的人做的，而是出自 Ruby 社區(qū)的開發(fā)者之手，兩個社區(qū)在最初的關(guān)系還有些不太和睦，原因是 Git 社區(qū)的人對于 GitHub 那群人拿 Git 去做商業(yè)化感覺很不爽……當(dāng)然，這些都是老開發(fā)者口中的陳年往事了。毫無疑問，GitHub 對于 Git 的普及做出了巨大的貢獻(xiàn)。Hamano 也表示：“ 有 GitHub 替我們做文檔以及用戶支持，何樂而不為呢。”

　　和 Git 的飛速發(fā)展形成鮮明對比的是，與 Linux 分道揚(yáng)鑣后的 BitKeeper 每況愈下，盡管后者是世界上首個商用級的分布式版本控制工具，但在 Git 誕生之后，BitKeeper 的市場占有率斷崖式下滑，幾乎淪落到無人問津的地步。Git 與 BitKeeper 的不同境遇可以說是 21 世紀(jì)初軟件行業(yè)的縮影，傳統(tǒng)的軟件商業(yè)模式在開源浪潮的席卷下迎來了前所未有的挑戰(zhàn)。

　　當(dāng)然，挑戰(zhàn)往往伴隨著機(jī)遇。于是，也有一批人開始反思傳統(tǒng)軟件商業(yè)模式的局限性，試圖尋找一種能夠適應(yīng)開源的全新商業(yè)模式。很快，以 Red Hat、MySQL、SugarCRM 為代表的開源行業(yè)公司開始崛起，他們的商業(yè)模式是利用開源項目來推出增值服務(wù)，即免費(fèi)向用戶提供軟件基礎(chǔ)功能，而通過收費(fèi)的增值服務(wù)來獲取利益。

　　比如 Red Hat 在 RHEL 推出的訂閱服務(wù)，在用戶免費(fèi)使用這款企業(yè)級 Linux 系統(tǒng)的前提下，他們可以通過訂閱，獲得每一版本產(chǎn)品一定時間內(nèi)的技術(shù)服務(wù)支持。這種支持包括但不限于系統(tǒng)升級、管理、維護(hù)；安全性和技術(shù)認(rèn)證支持；其他硬件和軟件支持。此外，Red Hat 還通過積極地投身開源社區(qū)為品牌贏得業(yè)內(nèi)認(rèn)可，從而促進(jìn)其他收費(fèi)產(chǎn)品的銷售。自 2001 年確立商業(yè)模式以來，Red Hat 已經(jīng)實現(xiàn)連續(xù) 19 個自然年的營收增長，創(chuàng)造了開源界的商業(yè)傳奇。

　　當(dāng) Red Hat 們利用開源項目取得前所未有的成功之后，許多傳統(tǒng)軟件開發(fā)商也開始意識到，開源已經(jīng)是無法阻擋的時代趨勢。2018 年，曾經(jīng)的“保守派”代表微軟收購 GitHub，進(jìn)一步布局開源；2019 年，藍(lán)色巨人 IBM 斥資 340 億美元收購 Red Hat，完成公司歷史上最大規(guī)模的收購……越來越多的軟件巨頭參與到了開源社區(qū)的建設(shè)中，積極擁抱開源。

　　值得一提的是，2016 年，在 Git 誕生 11 年之后，曾經(jīng)與 Linux 短暫攜手的 BitKeeper 宣布開源，只可惜為時已晚。

總結(jié)

以上是生活随笔為你收集整理的Git 15 周年：当年的分道扬镳，成就了今天的开源传奇的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。