[譯] Git 的歷史: 軟件版本控制的統治之路

Git 的歷史: 軟件版本控制的統治之路

在這裏插入圖片描述

在 2005 年,Linus Torvalds 迫切需要一個新的版本控制系統來維護 Linux 內核的開發。於是他花了一個星期的時間,從頭開始編寫了一個革命性的新系統,並將其命名爲 Git。十五年之後,該平臺成爲了這個競爭激烈領域裏面當之無愧的領導者

在全球範圍內,大量的初創企業、集體企業和跨國公司,包括谷歌和微軟,使用 Git 來維護它們軟件項目的源代碼。它們中有些公司擁有自己的 Git 項目,有些公司則通過商業託管公司使用 Git,比如 GitHub(成立於 2007 年),Bitbucket(成立於 2010 年)和 GitLab(成立於 2011 年)。其中最大的 GitHub 擁有 4000 萬註冊開發者 並在 2018 年被微軟以 75 億美元的天價收購。

Git(及其競爭對手)有時被分類爲版本控制系統(VCS),有時是源碼管理系統(SCM),還有時是修訂控制系統(RCS)。Torvalds 認爲生命太短暫而不必去區分這些定義,因此我們不必糾結於此。

Git 的吸引力之一在於它是開源的(就像 Linux 和 Android 那樣)。但是,還有其它開源的 VSC,其中包括協作版本系統(CVS)、SVN、Mercurial 和 Monotone,因此單憑這一點並不足以解釋它的優點。

關於 Git 市場主導地位的最好體現是 Stack Overflow 對開發人員的調查。調查結果顯示,2018 年 74289 名受訪者中有 88.4% 使用了 Git(高於 2015 年的 69.3%)。最接近的競爭對手是 Subversion,普及率爲 16.6%(低於 36.9%);Team Foundation 版本控制,從 2015 年的 12.2% 降爲 11.3%;Mercurial 普及率爲 3.7%(低於 7.9%)。事實上,Git 的優勢如此之大,以至於 Stack Overflow 的數據科學家都懶得在 2019 的調查中提出這個問題。

開源人員使用什麼來進行源碼控制?

|           2018         |          2015          |
| ---------------------- | ---------------------- |
| Git: 88.4%             | Git: 69.3%             |
| Subversion: 16.6%      | Subversion: 36.9%      |
| Team Foundation: 11.3% | Team Foundation: 12.2% |
| Mercurial: 3.7%        | Mercurial: 7.9%        |
|                        | CVS: 4.2%              |
|                        | Perforce: 3.3%         |

| 74,298 受訪者       | 16,694 受訪者       |

數據來源:Stack Overflow 2018/2015 開發者調查報告

開始

直到 2005 年 4 月,Torvalds 一直使用 BitKeeper(BK)管理着一個龐大的 Linux 內核源碼,這些源碼來自於完全不同的志願者開發團隊,Linux 是一個越來越受歡迎的類 UNIX 開源操作系統。BK 在當時是一個私有的付費工具,但是 Linux 的開發者可以免費使用它,直到 BK 的創始人 Larry McVoy 與一個 Linux 開發人員就不恰當地使用 BK 發生了爭執。

Torvalds 的聲明 到 Linux 郵件列表,都是關於他計劃利用一個工作“假期”來決定如何爲 Linux 找到新的 VCS,很明顯,他喜歡 BK,並對 Linux 不能再使用它而感到沮喪,而且他對競爭並不敢興趣。如之前提到的,這次假期誕生了 Git。Torvalds 將它命爲 Git 的原因有很多種說法,但實際上他只是喜歡這個詞,這是他從披頭士的歌曲《I’m So Tired》(第二節)中獲得靈感。

“搞笑的是,我所有的項目都是以我自己的名字命名,而這個項目的名字是‘Git’。Git 在英國俚語裏是‘愚蠢的人’的意思,” Torvalds 告訴我們。“它也有一個虛構的首字母縮寫 —— Global Information Tracker。但這實際上是一個 ‘backronym’, [事後]補上的。”

那麼,Torvalds 對 Git 的巨大成功感到驚訝嗎?“如果我說我能看到它即將成功,那絕對是在撒謊。我當然沒有。但是 Git 確實把所有的基礎都做對了。有什麼事情可以做得更好嗎?當然。但總的來說,Git 確實解決了一些與 VCS 有關的真正困難的問題。” 他說。

定義 Git 的目標

傳統上,版本控制是客戶端服務器,因此代碼位於單個存儲庫中,或者中央服務器的倉庫中。協作版本系統(CVS),Subversion 和 Team Foundation 版本控制(TFVC)都是客戶端/服務器系統的例子。

客戶機-服務器 VCS 在企業環境中運行良好,在企業環境中,開發受到嚴格控制,由具有良好網絡連接的內部開發團隊進行。如果有成百上千的開發人員進行協作,自願、獨立、遠程地工作,所有人都想要往代碼裏面添加新的東西,這對 Linux 等開源軟件(OSS)項目來說都很常見的,那麼這種協作就不太好用了。

BK 首創的分佈式 VCS 打破了這種模式。Git、Mercurial 和 Monotone 都遵循這個示例。對於分佈式 VCS 來說,最新版本的代碼副本在每個開發人員的設備上,從而使開發人員可以更輕鬆地獨立修改代碼。“BK 對使用模式的概念影響很大,確實應該得到所有的讚譽。但由於各種原因,我想讓 Git 的實現邏輯與 BK 完全不同,但‘分佈式 VCS’ 的概念確實是首要目標,BK 教會了我這一點的重要性,” Torvalds 說。“真正的分佈式意味着 fork 不是問題,任何人都可以 fork 一個項目並進行自己的開發,然後一個月或一年後回來說,‘看看我做的這件偉大的事情。’”

客戶機-服務器 VCS 的另一個主要缺點,特別是對於開源項目,是在服務器上託管中央存儲庫的人“掌握”了源代碼。然而,在分佈式 VCS 中,沒有中央存儲庫,只有許多拷貝複製,因此沒有人掌握或控制代碼。

“[這使得] 像 GitHub 這樣的網站成爲可能。當沒有包含源代碼的中心“主”位置時,你可以突然託管一些東西,而不需要遵循“一個倉庫來統治所有人”的策略。” Torvalds 說。

另一個核心目標是減少將新分支合併到主分支代碼或者 “tree”(組成源代碼層次結構的目錄)的痛苦。關鍵是爲每個對象分配一個加密哈希索引(唯一且安全的數字)。Git 並不是唯一使用哈希的版本控制器,將它提升到了一個新的高度,不僅將它們應用於每個新版本的文件內容,而且還使用它來確定它們之間的關係,包括 tree 和 commit 。這意味着,通過使用 “git diff” 指令,git 可以通過比較哈希的兩個索引,非常快速地識別出分支新的/待提交版本與源代碼之間的所有更改,甚至是整個 tree。“Git 索引的真正目的是作爲合併的中間步驟,這樣你就可以增量地修復衝突,” Torvalds 說。

在進行完全合併之前,這種中間步驟或暫存區的概念可進行版本之間的比較,並解決主要源代碼和附加內容之間的任何問題,這個概念是革命性的。然而,這並沒有得到那些習慣於其他 VCS 人的普遍認可。

指定一名維護人員

在編寫了 Git 之後,Torvalds 將其開放給開源社區進行審查和貢獻。在那些參與者中,有一位開發人員特別引人注目:Junio Hamano。因此,僅僅幾個月後,Torvalds 就可以抽出身來,專注於Linux,把維護 Git 的責任移交給 Hamano。“當涉及到代碼和功能時,他有明顯的、非常重要但難以具體描述的‘好品味’。”Torvalds 說,“Junio 確實應該接受所有的榮譽,作爲發起人,我理應獲得設計 Git 的榮譽。但作爲一個項目,Junio 是維護它的人,讓它成爲一個非常好用的工具。”

顯然,Junio 是一個不錯的選擇,因爲 15 年後,他仍然作爲一個仁慈的獨裁者來主導並維護 Git,這意味着他控制着 Git 未來發展的方向,對代碼的修改擁有最終的決定權,並且他保持着最多提交的記錄。

擴大 Git 的吸引力

早期支持 Hamano 的一些志願貢獻者到現在仍然在貢獻力量,儘管他們現在經常被一些依賴 Git 的公司全職僱用,並希望對其進行維護和改進。

其中一名志願者是 Jeff King,人們叫他 Peff,他在學生時代就開始參與貢獻了。他的第一次代碼提交是在 2006 年,在將他的代碼倉庫從 CVS 遷移到 Git 時發現並修復了 git-cvsimport 中的一個錯誤。“當時我是計算機科學與技術專業的研究生,”他說,“所以我花了很多時間在 Git 的郵件列表上,回答問題、修復 bug —— 有時是一些困擾我的問題,有時是對其他人報告的回覆。到 2008 年左右,我意外地成爲了主要貢獻者之一。 King 從 2011 年開始受僱於 Guthub 公司,在工作的同時,也爲 Git 貢獻自己的一份力量。

King 特別提到了 Git 的兩位貢獻者的傑出工作,他們都始於 2006 年,並幫助將 Git 的影響擴展到 Linux 社區之外:感謝 Shawn Pearce 爲 JGit 所做的工作,爲 Java 和 Android 生態系統打開了 Git 的大門;感謝 Johannes Schindelin 爲 Git for Windows 所做的工作,向 Windows 社區開放了 Git。他們隨後分別在谷歌和微軟工作。

“[Shawn Pearce] 是 Git 的早期貢獻者並且實現了 git-gui,這是 Git 的第一個圖形化界面。但更重要的是他在 JGit 上的工作,JGit 是 Git 的純 Java 實現” King 說。“這使得 Git 用戶的整個其他生態系統得以實現,並允許 Eclipse 插件,這是 Android 項目選擇 Git 作爲其版本控制系統的關鍵部分。他還寫了 Gerrit [在 Google 工作時],一個基於 Git 的代碼審查系統,用於 Android 和許多其它項目。不幸的是,Shawn 在 2018 年去世。”

Schindelin 現在仍然是 Git for Windows 發行版的維護者。**“由於 Git 是從內核社區中發展而來的,所以對 Windows 支持基本上是後來纔想起的,”。**King 說 “Git 已經被移植到很多平臺上,但大多數平臺都是類似於 Unix 風格。到目前爲止,Windows 是最大的挑戰。在 C 代碼中不僅存在可移植性問題,而且還存在使用 Bourne shell、Perl 等編寫的部分來發布應用程序的挑戰。Git for Windows 將所有這些複雜性整合到一個單一的二進制包中,對 Windows 開發人員使用 Git 的增長產生了重大影響。”

根據 somsubhra.com 統計,Git for Windows 迄今已被下載超過 1800 萬次。

建立 GitHub

Tom Preston-Werner 是由同事 Dave Fayram 介紹給 Git的,當時他在爲一家名爲 Powerset 的初創公司做輔助項目。“[用 Git ]創建分支、對其進行操作並輕鬆地將其合併回主分支的能力是革命性的。在這方面 Git 是驚人的。命令行界面需要適應,特別是有一個緩衝區的概念,” Preston Werner 說。提供基於 Git 的源代碼託管服務的機會是顯而易見的。**“託管 Git 倉庫沒有任何好的選擇,因此,這對易用性來說是一個大障礙。還缺少一個現代的 web 界面。作爲一名 web 開發人員,我認爲我可以通過輕鬆託管 Git 倉庫和促進協作來改善這種情況,這是 Git 可以做到的,但並不容易,”**他補充道。

Preston-Werner 與 Chris Wanstrath、Scott Chacon 和 P.J. Hyett 合作,於 2007 年底開始開發 GitHub 項目。GitHub 幫助 Git 成爲主流,不僅使它更易於使用,還將其傳播到 Linux 社區之外。由於 GitHub 的創始人是 Ruby 開發人員,而且 GitHub 是用 Ruby 編寫的,所以這個詞很快就在這個社區中傳開了,並在被 Ruby on Rails 開發框架採用時大獲成功。

“到 2008 年年中,Ruby on Rails 轉向了 GitHub,整個 Ruby 社區似乎都很快跟進。我認爲,這種背書,加上 Ruby 開發人員願意接受更新、更好的技術,這些對我們的成功都至關重要。”Preston-Werner 說。“其他項目,如 Node.jsHomebrew,都是從 GitHub 開始的,幫助將 Git 引入了新的社區。”

Preston-Werner 在 2014 年辭去了 GitHub CEO 一職,當時有人指控該公司存在欺凌行爲和不適當的投訴程序,這些問題或許是該公司發展過快的徵兆。

今天,根據 GitHub 自己的數據,GitHub 有超過 4000 萬註冊開發者。這使得它比競爭對手 —— Bitbucket 擁有1000萬用戶的規模要大得多,而 GitLab 則表示,它擁有“數百萬”用戶。

被 Android 採用

許多公司使用 GitHub 企業版GitLab 或 Bitbucket 來託管軟件項目。但是,最大的 Git 安裝往往是內部託管的 —— 因此是在公共視野之外 —— 通常進行定製的修改。

Google 是第一個 Git 的主要採用者(因此也提供了大量的支持),谷歌在 2009 年 3 月決定將 Git 用於 Android 項目,Android 是一個基於 Linux 的手機操作系統。作爲開源項目,Android 需要一個允許大量開發人員克隆、使用和貢獻代碼的平臺,並且無需購買特定的工具許可證書。

當時,Git 被認爲不足以管理如此龐大的項目,因此團隊構建了一個超級倉庫,可以委託給子 Git 倉庫。然而,谷歌表示:**“超級倉庫並不是要取代 Git,只是爲了讓 Git 更容易使用。**爲了幫助查看倉庫和管理、審查對源代碼的更改,Pearce 領導的團隊 —— 創建了 Gerrit

Microsoft 改變態度

考慮到開源社區和微軟之間相互仇恨的歷史,這個軟件巨頭肯定是 Git 最不可能的支持者。2001 年,當時的微軟首席執行 Steve Ballmer 甚至稱 Linux 爲癌症,微軟也有自己的競爭對手 VCS TFVC。

Schindelin 在 Git for Windows 上工作了多年,而微軟沒有任何人注意到他的努力。但是,到 2015 年,當他在微軟工作時,文化發生了巨大的轉變。他開玩笑說:“如果你在 2007 年問我,或者在 2011 年問過我,我是否會擁有一臺 Windows 機器,甚至在微軟工作,我都會笑死的。

這一文化轉變的第一個證據出現在 2012 年,當時微軟開始(實際上)爲 Git 開發資源庫 libgit2(一個 Git 開發資源庫)做出貢獻,以幫助加快 Git 應用程序的速度,然後將其嵌入到開發工具中。Edward Thomson,微軟團隊的一員,仍然是 libgit2 的維護者。

2013 年,微軟宣佈對其開發工具 Visual Studio(VS)提供 Git 支持,並通過 Azure DevOps(當時稱爲 Team Foundation Service)的雲計算工具和服務套件提供 Git 託管,作爲其自身 TFVC 的替代方案,這一消息震驚了科技界。

更值得注意的是,從 2014 年開始,在新的開源友好型 CEO Satya Nadella 的領導下,微軟通過 One Engineering System(1ES)計劃,在 Git 上逐步實現了內部軟件開發的標準化。Azure DevOps 團隊在 2015 年開始使用自己的 Git 服務作爲自己源碼的存儲庫,這是一個先例。

2017年,微軟 Windows 產品套件的整個開發工作轉移到了由 Azure 託管的 Git 上,創建了世界上最大的 Git 存儲庫。這包括相當大的調整以幫助 Git 擴展。Git 的虛擬文件系統(它是開源的)並沒有將整個 300GB 的 Windows 存儲庫下載到每個客戶端設備,而是確保只將適當的文件下載到每個工程師的計算機上。

正如 Schindelin 所指出的:“當像微軟這樣歷史悠久的大公司決定 Git 可以投入企業級使用時,商業界會非常仔細地傾聽。我認爲這就是爲什麼 Git 至少在目前爲止是‘贏家’的原因。

收購!

2018 年 6 月,微軟宣佈將以 75 億美元的價格收購 GitHub,這讓人大吃一驚。但當你看事實的時候,也許會覺得這次收購並不是那麼出乎意料。

微軟從 2014 年開始參與 GitHub,當時。.Net 開發者平臺是開源的。據 GitHub Octoverse 2019 調查顯示,目前 GitHub 上貢獻最多的兩個項目都是微軟的產品 —— Visual Studio codeMicrosoft Azure,而 OSCI/EPAM 在 2019 年的研究顯示,微軟是 GitHub 上最大的企業貢獻者。並且,如前所述,微軟已經在 Git 上標準化了內部開發。

開源項目的貢獻者數量

|                項目                    |  貢獻人數     |
| -------------------------------------- | ------------- |
| Microsoft/vscode                       | 19.1k         |
| MicrosoftDocs/azure-docs               | 14k           |
| flutter/flutter                        | 13k           |
| firstcontributions/first-contributions | 11.6k         |
| tensorflow/tensorflow                  | 9.9k          |
| facebook/react-native                  | 9.1k          |
| kubernetes/kubernetes                  | 6.9k          |
| DefinitelyTyped/DefinitelyTyped        | 6.9k          |
| ansible/ansible                        | 6.8k          |
| home-assistant/home-assistant          | 6.3k          |

來源:GitHub Octoverse 2019 
在 GitHub 上的開源項目的公司中活躍的貢獻者的數量

|  公司        |     活躍貢獻者        |
| -------------| -------------------- |
| Microsoft    | 4,859                |
| Google       | 4,457                |
| Red Hat      | 2,766                |
| IBM          | 2,108                |
| Intel        | 2,079                |
| Facebook     | 1,114                |
| Amazon       | 850                  |
| Pivotal      | 767                  |
| SAP          | 732                  |
| GitHub       | 663                  |

來源: OSCI/EPAM research January 2020 

儘管如此,這次收購還是引起了一些 GitHub 用戶的擔憂,他們還記得在開源社區的眼中刺 Ballmer 領導下的老微軟。Bitbucket 和 GitLab 都聲稱看到了從 GitHub 遷移到他們平臺的項目激增。

不過,Torvalds 並不這麼認爲。“我對微軟的收購沒有任何保留意見,部分原因是 Git 的基本分佈式特性 —— 它避免了政治問題,另一方面也避免了可怕的‘託管公司控制項目’。我不擔心的另一個原因是,我認爲微軟現在是一家不同的公司…微軟根本不是開源的敵人。”他說,“在純粹個人層面上,當我聽說微軟在 GitHub 上花了很多錢時,我只是說,‘現在我開始的兩個項目已經變成了價值數十億美元的產業’,沒有多少人能這麼說。我也不只是一個“曇花一現的人”。
“這是‘生活幸福’的一部分。我很高興我對世界產生了積極而有意義的影響。我個人可能沒有直接從 Git 上賺到任何錢,但它給了我能夠做我真正的工作和激情,[Linux]。我不再是一個飢腸轆轆的學生了,我作爲一個受人尊敬的程序員做得很好。所以其他人在 Git 上獲得的成功絕不會讓我感到沮喪。”

貢獻者。感謝:Linus Torvalds,Git 和 Linux 的創始人;Johannes Schindelin,微軟軟件工程師,Git for Windows 的維護者;Jeff King, GitHub 的 OSS 開發人員;Tom Preston Werner,Chatterbug 的聯合創始人,GitHub 的聯合創始人;Edward Thomson,GitHub 的產品經理,以及 libgit2 的維護者;Ben Straub,Pro Git 的作者;Evan Phoenix,Rubinius 的創建者;GitLab 高級後端工程師 Christian Couder;GitLab首席營銷官 Todd Barr;EPAM 交付管理總監 Patrick Stephens。

本文出自 Behind the Code —— 由開發者創建的服務於開發者的媒體平臺。通過訪問 Behind the Code,可以發現更多的文章和視頻!

想要參與貢獻?出版!

Twitter 上關注我們吧,保持關注!

Blok 聲明

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章