Facebook為什么要棄用Git？

閱讀本文大概需要 4 分鐘。

來自：AI大模型實(shí)驗(yàn)室

推薦一個(gè)程序員編程資料站：

http://cxyroad.com

2024年IDEA最新激活方法

后臺(tái)回復(fù)：激活碼

CSDN免登錄復(fù)制代碼插件下載：

CSDN復(fù)制插件

以下是正文。

---

本文作者 Greg Foster 是 Graphite.dev 聯(lián)合創(chuàng)始人兼 CTO。作者說他很好奇當(dāng)年 Facebook 為什么會(huì)放棄 Git，轉(zhuǎn)而使用 Mercurial 作為版本控制工具，他通過查找資料，看技術(shù)講座以及與當(dāng)時(shí)參與遷移到 Mercurial 的工程師交流找到了答案，我們一起來看看 Greg Foster 找到的答案是什么。

我參與開發(fā)的 Graphite 項(xiàng)目，其實(shí)很大程度上受到了 Facebook 內(nèi)部工具的啟發(fā)。當(dāng)我和朋友們開始著手創(chuàng)辦一家公司時(shí)，我還沒聽說過 Mercurial，盡管我喜歡搗鼓各種開發(fā)工具。

此前，我的工作經(jīng)驗(yàn)包括個(gè)人項(xiàng)目、大學(xué)作業(yè)、在 Google 做 iOS 開發(fā)和在 Airbnb 做基礎(chǔ)設(shè)施開發(fā)。對我來說，Git 就像水一樣常見。它如此普及，以至于我認(rèn)為它是唯一可行的代碼管理工具。

有趣的是，在 Airbnb 我的工位和 Mercurial 專家 Gregory Szorc 中間就隔了幾個(gè)人，當(dāng)時(shí)我只知道他是一個(gè)很好的同事，對他的專業(yè)背景一無所知。

2021 年，我的同事 Tomas 和 Nick 改變了我的看法。他們來自 Facebook，令我驚訝的是，他們幾乎不懂 Git。他們對 Mercurial 的使用模式和 Facebook 的 “stacked diffs” 工作流程非常熟悉。

隨著在一起工作的時(shí)間變長，他們讓我看到了非 Git 工具和模式的優(yōu)勢，我們最終決定將公司早期的方向轉(zhuǎn)向?yàn)?GitHub 開發(fā)者引入 stacked diffs。在這個(gè)過程中，我們創(chuàng)建了一個(gè)將 Mercurial 的理念融入 Git 的命令行工具。

這篇文章是關(guān)于過去三年來一直困擾我的一個(gè)問題的，即，為什么 Facebook 的員工不用 Git？為什么他們選擇 Mercurial 并在其上構(gòu)建自定義工作流程？

我知道 Google 不用 Git，那是因?yàn)?Google 的工程設(shè)計(jì)比 Git 早了五年多。但 Facebook 和 Git 幾乎同時(shí)在 2004 年誕生，到 Facebook 認(rèn)真評(píng)估版本控制工具時(shí)，Git 已經(jīng)比 Mercurial 更受歡迎了。那為什么 Facebook 仍然不用 Git 呢？

研究這個(gè)問題的人雖然不多，但我覺得很有趣。如果 Facebook 在 2010 年代初期傾向于使用 Git 并為其做出貢獻(xiàn)，那么今天的工程界可能會(huì)有所不同。Git 可能會(huì)更加用戶友好，并且原生支持 stacked changes。GitHub 可能會(huì)更好地支持閉源軟件開發(fā)。

像 Uber 和 Pinterest 這樣的由前 Facebook 員工創(chuàng)辦的公司也可能使用 Git 和 GitHub 作為他們的版本控制工具，而不是 Phabricator 和 Mercurial，從而在過去十年中形成一個(gè)更統(tǒng)一的生態(tài)系統(tǒng)。

但 Facebook 沒有堅(jiān)持使用 Git 作為他們的主要代碼倉庫。相反，他們選擇了 Mercurial 作為版本控制工具，并逐步在其上添加自定義工具。為什么會(huì)這樣？首先，我通過 Google 搜索找到了一篇權(quán)威的博客文章：

https://engineering.fb.com/2014/01/07/core-infra/scaling-mercurial-at-facebook/

這篇十年前的文章以及一些后來的 YouTube 技術(shù)講座，給了我一個(gè)初步的答案：“因?yàn)樾阅軉栴}。 ”

但我想更深入地了解一下，聽聽當(dāng)初做出決定的工程師們是怎么想的。在一位同事的幫助下，我在前 Facebook 員工群組中發(fā)布了這個(gè)問題，咨詢相關(guān)問題。我還給兩位最初負(fù)責(zé)遷移到 Mercurial 的工程師發(fā)了郵件，他們很友好地給我打了電話，并私下講述了這個(gè)項(xiàng)目的個(gè)人經(jīng)歷。

這是我所了解到的關(guān)于 Facebook 為什么不使用 Git 的全部原因 —— 希望這篇文章能進(jìn)一步記錄我們 2024 年工具選擇的原因。

注意 ：我從未在 Facebook 工作過，這是我作為一個(gè)外人對這件事的最佳理解。我與一些參與該項(xiàng)目的人交流，并獲得了他們的許可，記錄下了他們向我解釋的內(nèi)容。

為什么 Facebook 要放棄 Git？

根據(jù) 2014 年 Facebook 的博客介紹，F(xiàn)acebook 起初是使用 Git 的。正如人們猜測的那樣，當(dāng)時(shí)它是他們源代碼控制系統(tǒng)的默認(rèn)選擇。但大約在 2012 年，他們開始遇到擴(kuò)展限制。

文章稱他們的代碼庫 “比 Linux 內(nèi)核大很多倍，而 Linux 內(nèi)核有 1700 萬行代碼和 44000 個(gè)文件。” 具體來說，Git 操作開始讓工程師感到緩慢 。雖然沒有慢到無法忍受的地步，但已經(jīng)慢到足以引起調(diào)查。

關(guān)鍵問題在于 “stat-ing” 所有文件的過程。“Git 檢查每個(gè)文件，隨著文件數(shù)量的增加自然變得越來越慢。” 工程師們嘗試運(yùn)行模擬，創(chuàng)建了一個(gè)匹配 Facebook 未來幾年預(yù)期規(guī)模的虛擬倉庫。

結(jié)果令人震驚 —— 基本的 Git 命令需要超過 45 分鐘才能完成。正如項(xiàng)目中的一位初始工程師所說，“這不是你能等到所有工程師都在抱怨時(shí)才去解決的問題。到那時(shí)，問題就難以處理了。嘗試降低損失就是一項(xiàng)艱巨的任務(wù)了，更不用說提出一個(gè)更好的解決方案了。”

于是，一群不拘一格的軟件工程師開始研究解決方案。首先，他們聯(lián)系了 Git 的維護(hù)人員，看看要讓 Git 更好地支持大型代碼倉庫需要做些什么。

以下是與 Git 維護(hù)人員的郵件交流中的一些精采對話 ——12 年后，再讀起這些消息，我仍然覺得有些沮喪：

聽起來你把所有東西都放在一個(gè) .git 里。把這個(gè)龐大的倉庫分割成多個(gè)較小的 .git 倉庫。

雖然你可以這樣做，但這不是一個(gè)好主意，你應(yīng)該分割倉庫。

我同意。我在一個(gè)有多年開發(fā)歷史的公司工作，有幾個(gè)巨大的 CVS 倉庫，我們正在慢慢地將代碼庫從 CVS 遷移到 Git。分割這些東西。這將使你能夠更好地重新組織東西，我認(rèn)為沒有任何缺點(diǎn)。

雖然 Git 可以更好地處理大型倉庫（特別是在交互式 rebase 中應(yīng)用提交時(shí)似乎會(huì)在較大的倉庫中變慢），但對 130 萬個(gè)文件進(jìn)行 stat-ing 你能做的也只有這么多了。

Git 的回應(yīng)并不積極 —— 對一個(gè)充滿大型單一代碼庫來說，這種方式?jīng)]有多大改變。Git 的維護(hù)者們拒絕改進(jìn)性能，反而建議 Facebook 分片他們的單一代碼庫。但是，分片對 Facebook 團(tuán)隊(duì)來說根本不可能實(shí)現(xiàn)，他們對 Git 不愿意擴(kuò)展的態(tài)度感到驚訝。一般來講，大型科技公司提供的免費(fèi)開源勞動(dòng)力是一個(gè)備受歡迎的禮物，可以確保項(xiàng)目長久存在。

話雖如此，但 Git 也沒有義務(wù)屈從于 Facebook 的要求 —— 我并不打算把他們描繪成這個(gè)故事的 “反派”。因?yàn)榘?Facebook 的要求去做某件事并不是合理的生存方式。有趣的是，兩年后當(dāng)看到 Facebook 為 Mercurial 做出有價(jià)值的改進(jìn)后，Git 維護(hù)者似乎改變了態(tài)度：

他們向郵件列表發(fā)了關(guān)于 Git 性能問題的郵件。從我的觀察來看，反饋相對較少。

我的印象是，他們可能也有這種感覺，即 Git 開發(fā)社區(qū)對大規(guī)模存儲(chǔ)庫的性能問題沒那么上心。

所以問題是，Git 社區(qū)是否有興趣在這種大規(guī)模場景中保持競爭力 —— 而 Mercurial 似乎在這方面已經(jīng)做到開箱即用了。

十年后，Git 在更好地支持單一代碼庫方面取得了明顯進(jìn)展。

考慮的替代方案

2012 年，Git 的替代方案很少。團(tuán)隊(duì)考慮了閉源的 Perforce，即 Google 之前的源代碼控制解決方案。在與 Perforce 售前工程師的早期調(diào)查電話中，F(xiàn)acebook 指出了 Perforce 在讀寫節(jié)點(diǎn)之間本地一致性的架構(gòu)缺陷。但他們的回應(yīng)不能讓人放心 —— 售前工程師們并不清楚這個(gè)問題，也沒有計(jì)劃來解決這個(gè)問題。

其他解決方案，如 Bitkeeper，也被考慮過，但很快都被排除。最后一個(gè)選項(xiàng)是 Mercurial。它的性能與 Git 相似，但架構(gòu)更清晰 。Git 是一個(gè)復(fù)雜的 Bash 和 C 代碼網(wǎng)絡(luò)，而 Mercurial 是用 Python 面向?qū)ο蟮木幋a模式構(gòu)建的，設(shè)計(jì)上易于擴(kuò)展。

其中一位調(diào)查工程師對在之前已經(jīng)有了豐富的 Mercurial 使用經(jīng)驗(yàn)，因此團(tuán)隊(duì)決定參加在阿姆斯特丹舉行的 Mercurial 黑客松以進(jìn)一步調(diào)查。

他們發(fā)現(xiàn)了一個(gè)易于擴(kuò)展的系統(tǒng)和一個(gè)對 Facebook 團(tuán)隊(duì)的積極改變非常歡迎的維護(hù)者社區(qū)。

遷移整個(gè)工程組織

在阿姆斯特丹黑客松之后，F(xiàn)acebook 團(tuán)隊(duì)已經(jīng)下了決心。剩下的任務(wù)是說服公司其他人進(jìn)行遷移。這是一項(xiàng)令人望而生畏的任務(wù) —— 工程師們對工具的變化極其敏感（類似于 Vim 和 Emacs 之爭），更換源代碼控制系統(tǒng)是一件大事。

團(tuán)隊(duì)盡可能平穩(wěn)地推進(jìn)，以免引起其他工程師的反對。接下來發(fā)生的事情聽起來像是內(nèi)部開發(fā)工具遷移的典范。團(tuán)隊(duì)花了幾個(gè)月的時(shí)間讓工程師們接受了遷移到 Mercurial 的可能性，并花時(shí)間映射 Git 和 Mercurial 之間的所有常見命令和工作流程。他們甚至收集了全公司使用 Git 命令的頻率，并特別記錄了如何在 Mercurial 中執(zhí)行最頻繁的操作。

其次，他們提供了開發(fā)人員表達(dá)擔(dān)憂和討論可能在新系統(tǒng)中遇到任何邊緣情況的機(jī)會(huì)。起初，團(tuán)隊(duì)以為他們會(huì)陷入關(guān)于復(fù)雜合并情況的爭論。但令他們驚訝的是，他們的同事們表現(xiàn)得都很友好。“沒有人站起來大喊大叫說他們的情況特殊。”

最后，他們承諾進(jìn)行遷移，并將公司切換到 Mercurial。剩下的事情大家都知道了。Facebook 為 Mercurial 做出了性能改進(jìn)，使其成為大型單一代碼庫的最佳選擇。Evan Priestley 擴(kuò)展了 Phabricator 以支持 Mercurial。Facebook 利用 Mercurial 的 “diffs” 概念創(chuàng)建了 “堆疊” 的模式，解鎖了新的代碼審查并行化。

前 Facebook 員工離開后到新公司，帶來了他們的工作流程，創(chuàng)造了一個(gè)小而熱情的堆疊 diff 愛好者社群。最終，我遇到了其中一些愛好者，并決定將我的 20 多年奉獻(xiàn)給將 Mercurial 風(fēng)格的堆疊 diff 帶到 Git 和 GitHub 上。

結(jié)束語

這個(gè)故事的教訓(xùn)是什么？反思這些引文和采訪，我想起了一個(gè)經(jīng)典的智慧：歷史上許多關(guān)鍵技術(shù)決策都是由人而不是技術(shù)推動(dòng)的。

Facebook 采用 Mercurial 并不是因?yàn)樗?Git 性能更好。他們采用它是因?yàn)榫S護(hù)者和代碼庫對合作的態(tài)度更開放。Facebook 工程師與 Mercurial 維護(hù)者進(jìn)行了面對面的交流，他們喜歡這種合作方式。在說服整個(gè)工程團(tuán)隊(duì)之前，這一決定是經(jīng)過充分溝通和深思熟慮的 —— 而不僅僅是因?yàn)槟稠?xiàng)技術(shù)嚴(yán)格優(yōu)于另一項(xiàng)。

善良和開放在開發(fā)工具的世界中非常重要，我希望在我為源代碼控制歷史做出貢獻(xiàn)時(shí)繼續(xù)保持這種價(jià)值觀。

<END>

推薦閱讀：

Java8中一個(gè)極其強(qiáng)悍的新接口，炸裂！很多人沒用過

幾行代碼，搞定 SpringBoot 接口惡意刷新和暴力請求！

     

      程序員在線工具站：cxytools.com
     
推薦一個(gè)自己寫的工具站：http://cxytools.com，專為程序員設(shè)計(jì)，包括時(shí)間日期、JSON處理、SQL格式化、隨機(jī)字符串生成、UUID生成、文本Hash...等功能，提升開發(fā)效率。
     

      ?戳閱讀原文直達(dá)！                                  朕已閱