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

時間 2020-03-17

標籤 git 歷史軟件版本控制統治之路欄目 Git 简体版

原文原文鏈接

原文地址：The History of Git: The Road to Domination in Software Version Control

原文做者：Andy Favell

譯文出自：掘金翻譯計劃

本文永久連接：github.com/xitu/gold-m…

譯者：fireairforce

校對者：Long Xiong, 司徒公子

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

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

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

Git（及其競爭對手）有時被分類爲版本控制系統（VCS），有時是源碼管理系統（SCM），還有時是修訂控制系統（RCS）。Torvalds 認爲生命過短暫而沒必要去區分這些定義，所以咱們沒必要糾結於此。react

Git 的吸引力之一在於它是開源的（就像 Linux 和 Android 那樣）。可是，還有其它開源的 VSC，其中包括協做版本系統（CVS）、SVN、Mercurial 和 Monotone，所以單憑這一點並不足以解釋它的優勢。linux

關於 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 的調查中提出這個問題。android

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

|           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 發生了爭執。ios

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

「搞笑的是，我全部的項目都是以我本身的名字命名，而這個項目的名字是‘Git’。Git 在英國俚語裏是‘愚蠢的人’的意思，」 Torvalds 告訴咱們。「它也有一個虛構的首字母縮寫 —— Global Information Tracker。但這其實是一個 ‘backronym’, [過後]補上的。」程序員

那麼，Torvalds 對 Git 的巨大成功感到驚訝嗎？「若是我說我能看到它即將成功，那絕對是在撒謊。我固然沒有。可是 Git 確實把全部的基礎都作對了。有什麼事情能夠作得更好嗎？固然。但總的來講，Git 確實解決了一些與 VCS 有關的真正困難的問題。」他說。github

定義 Git 的目標

傳統上，版本控制是客戶端服務器，所以代碼位於單個存儲庫中，或者中央服務器的倉庫中。協做版本系統（CVS），Subversion 和 Team Foundation 版本控制（TFVC）都是客戶端/服務器系統的例子。web

客戶機-服務器 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.js 和 Homebrew，都是從 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 code 和 Microsoft 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 聲明