根據最新的調查數據，高達 93.87% 的開發者選擇使用 Git 作為他們的代碼版本控制系統。然而，令人驚訝的是，在2024年依然有少數知名公司并未采用 Git。據悉，Facebook 選擇的是 Mercurial，而 Google 則青睞于Piper。那么，這些行業巨頭為何選擇不隨大流，轉而采用其他版本管理系統呢？這些系統又各自具備哪些獨特之處呢？接下來，本文將深入探討這些問題。

圖片

Git 是一個分布式版本控制系統，用于跟蹤代碼的變化并協調多個開發人員在同一項目上的工作。Git 是由 Linus Torvalds 為了管理 Linux 內核開發而創建的，如今已經成為開源項目中最流行的版本控制系統，沒有之一。

Mercurial

是什么？

Facebook最初選擇了Git，但在代碼規模急劇增長后，他們開始遭遇Git性能方面的限制。特別是在執行類似"stat"的操作時，隨著文件數量的增加，Git的性能開始變慢。盡管團隊嘗試聯系Git項目的維護者以改進這些問題，但最終他們決定不再依賴Git，并轉而選擇了Mercurial，因為Mercurial的架構更加干凈，且在面對大型monorepo時性能較好。Facebook也曾考慮過其他備選方案，比如閉源的Perforce和Bitkeeper，但最終選擇了Mercurial，因為其性能與Git相當，而且有清晰的架構，易于擴展。

Mercurial 是一個分布式版本控制系統，用于跟蹤項目的變化和管理文件的歷史記錄。它允許開發人員協作，跟蹤代碼更改，并管理源代碼庫的版本。Mercurial 提供了一種靈活的工作流程，能夠適應不同團隊和項目的需求。

圖片

Mercurial 具有以下特點和優勢：

• 性能：Mercurial能夠良好地支持大型單一代碼庫，擁有較好的性能表現，特別適合于大規模項目。
• 易于擴展：Mercurial系統易于擴展，同時其設計相對清晰，采用了面向對象編程模式，由Python編寫。
• 與維護者合作：Facebook團隊與Mercurial的維護者進行了面對面的交流，喜歡這個合作伙伴的理念，而且維護者社區對Facebook團隊的大膽改變給予了積極的歡迎。

為什么？

Facebook選擇Mercurial而不是Git的原因主要包括：

• 性能問題：在使用Git時，Facebook遇到了擴展性上的限制，尤其是對于大型單庫的操作效率。
• 合作與支持：Mercurial 維護者和代碼庫更愿意與其合作，Facebook的工程師們得到了維護者和社區的支持。
• 社交化遷移過程：Facebook 團隊花了數月時間社交化地進行遷移到Mercurial的可能性，并且經過全公司的調查和討論，使整個遷移過程更為順利。

圖片

總之，Facebook 選擇 Mercurial 并非僅僅因為它比Git性能更好，而更多地是因為 Mercurial 的維護者和代碼庫更加愿意與Facebook合作，并且在工程團隊中得到了有效的傳播和溝通。

Piper

谷歌公司內部主要使用的是自行研發的版本管理工具 Piper 來管理代碼，而不是Git。谷歌的 90% 以上的代碼都存放在Piper中。對于那些開源的、需要外部協作的項目，如 Android 項目和 Chrome 項目，谷歌會選擇使用 Git。

圖片

是什么？

Piper 與其他版本管理系統不同，它只有一個代碼倉庫。也就是說，Google 將所有代碼都放在了一個代碼倉庫，整個公司使用不同語言編寫的超過10億文件，近百 TB 源代碼都存放在自行開發的版本管理系統 Piper 中，只當項目開源且需要外部協作時，才會使用業界流行的 Git。

Piper 整個倉庫采用樹狀結構，每個團隊有自己的目錄，目錄路徑就是代碼的命名空間。每個目錄都有負責人，負責批準該目錄的文件變動。在權限控制方面，Piper支持文件級別的權限控制，大部分代碼對所有用戶可見，但重要的配置文件和機密的關鍵業務設有訪問限制。

在工作流方面，開發者先創建文件的本地拷貝，這叫做“工作區”。完成開發后，工作區的快照會共享給其他開發者進行代碼評審。只有通過評審的代碼才能合并到中央倉庫。谷歌采用“主干開發”的方式，代碼一般提交到主干的頭部，避免了合并分支時的麻煩。所有代碼在合并進倉庫之前，都必須進行代碼評審，大部分評審對所有人開放，任何谷歌員工都可以對代碼提意見或者提交變動。

為什么？

那為什么 Google 使用 Piper，而不是使用 Git 呢？

• 規模：Google 的代碼庫包含約十億個文件，3500 萬次提交記錄，這遠遠超出了一般代碼庫的規模。Piper 被設計用來處理這種大規模的代碼庫，以及數以萬計的開發者對單一代碼庫的共享，這使得它更適合于谷歌的特殊需求。
• 安全性：Piper 被設計時考慮了安全功能，包括支持文件級別的訪問控制列表，對文件讀寫訪問進行日志記錄等。這些功能對于谷歌來說是非常重要的，因為他們的源代碼是公司最重要的資產之一。這種強調安全性和權限控制的設計使得 Piper 更適合谷歌的需要。
• 操作和擴展性：Piper 的工作流程被設計成能夠滿足 Google 這樣規模的組織的需求。Piper 提供了一種基于主干的開發模式，這使得大多數開發人員可以在“頭部”進行開發，也就是主干代碼的最新版本。此外，Piper 還具有基于云的存儲后端和支持工作區快照的系統，這些特性都使得它更適合谷歌這樣規模龐大的組織。

SVN

說完了 Facebook 和 Google 使用的版本控制系統，最后再來簡單了解一下使用率排在第二的版本控制系統——SVN。

SVN，全稱 Subversion，是一個開放源代碼的版本控制系統。它主要用于管理和跟蹤文件和目錄的變化，允許多個人在同一個項目上同時工作，并且可以追蹤每個人的修改，以便在需要時進行版本回退或合并。

SVN的工作原理是將項目文件和版本歷史存儲在中央資料檔案庫中，這個檔案庫可以記錄每一次文件的變動，因此用戶可以把檔案恢復到舊的版本或瀏覽文件的變動歷史。SVN通過高效的分支管理系統實現多個人共同開發同一個項目，實現共享資源，并最終實現集中式的管理。

Git 的使用率比 SVN 多的原因主要有以下幾點：

• 分布式特性：Git是分布式的版本控制系統，每個開發者本地都擁有完整的代碼庫，可以獨立地進行代碼提交、分支創建等操作，無需依賴于中央服務器。而SVN則是集中式的版本控制系統，所有的版本信息都存儲在中央服務器上，開發者需要通過中央服務器進行代碼的提交和更新。因此，Git更適用于網絡不穩定或團隊協作地域分布廣泛的場景。
• 性能優勢：由于Git的操作大多在本地進行，因此其性能通常比SVN快，特別是在大型項目或網絡狀況不佳的情況下。SVN在處理大型存儲庫和大文件時可能會遇到性能瓶頸。
• 靈活性和分支策略：Git支持多種分支策略，可以根據項目需求選擇合適的策略，使得團隊協作更加靈活。相比之下，SVN在分支支持方面相對較弱，分支管理較為復雜。
• 社區支持和生態發展：Git在開源社區中得到了廣泛的支持和應用，擁有龐大的用戶群體和豐富的生態資源。這使得Git在功能更新、問題解決等方面更具優勢。

通常情況下，SVN 在以下情況下更適用：

• 集中式管理需求：當團隊更習慣于集中式的版本控制系統時，SVN 可能更為適合，因為它對于權限控制和集中式管理提供了更直接的支持。
• 簡單操作：對于那些不需要復雜分支和合并操作的項目，SVN 提供了更為直觀的界面和操作方式。
• 二進制文件處理：在處理大型二進制文件時，SVN 通常比 Git 更加高效，因為 SVN 對二進制文件的處理較為友好。
• 穩定性需求：在一些企業環境中，特別是傳統的軟件開發公司，他們可能更傾向于使用 SVN，因為它有著更長時間的發展歷史和更成熟的穩定性。

總結

Facebook選擇Mercurial的原因主要是出于性能考量和合作與支持的考慮。隨著代碼規模的急劇增長，Facebook發現Git在大型單庫操作上的性能存在限制。與此同時，Mercurial的維護者和社區更愿意與Facebook合作，提供了良好的支持和溝通渠道。這使得Facebook工程師們得到了必要的支持，并順利完成了從Git到Mercurial的遷移。

而Google選擇自行研發的Piper系統則是基于其特殊的代碼庫規模和安全性需求。Google的代碼庫規模龐大，包含數億個文件和大量提交記錄，這要求版本管理系統具備處理大規模代碼庫的能力。此外，Google還非常注重源代碼的安全性，因此Piper系統在設計時考慮了安全功能，如文件級別的訪問控制和日志記錄等。