本文源自 Hacker News 熱帖，原文 Twenty Years Is Nothing，作者 Adrian Kosmaczewski。
在之前的文章中，我們曾稱英語在我們的行業中如此普遍，以至於沒有人質疑其使用。同樣，Git 也是如此。很難想象僅僅二十年前，代碼版本控制工具的格局更加多元化，選擇其中一種工具比今天要複雜得多。事實上，當時 Git 還沒有出現在雷達上。討論 Git 的霸權是好是壞前，我們先回到過去稍作停留。
卡洛斯·加德爾在其著名的探戈中唱道：
To feel… that life is a breath of fresh air,
that twenty years is nothing,
that, feverish, the gaze
wandering in the shadows seeks and names you.
二十年前
2004 年 Steve McConnell 的「代碼大全」第二版出版了。在這本厚達 900 頁鉅著的第 668 頁，我們找到了整本書中唯一關於代碼版本控制主題的內容：大約四分之三頁長。沒有別的內容了。ChatGPT 可以輕鬆地用一個短句總結所有內容：版本控制軟件很好，並帶來了幾個重要好處。沒有太多值得一提的東西，此時，我們距離 GitOps 還相去甚遠。
同年，也就是 20 年前，Subversion 1.0 問世，和「Code Complete」幾乎同時發佈。Subversion 是什麼？可能是計算曆史上最短命的好主意之一。Subversion（或 svn）本應比 CVS 更好 [不是美國著名連鎖藥房 CVS Pharmacy]，是 Concurrent Versions System，版本控制系統。比 CVS 更好在當時是指具有事務性（數據庫有人懂嗎？）並對分支支持更好些。那時候我們還沒有很高的追求，孩子們。
然而 Linus Torvalds [小編注：Linux 內核的創始人和首席開發者] 卻有更高追求。2004 年，Linux 內核開發者們因 BitKeeper 產生越來越大的爭議 - BitKeeper 是專有的、分佈式版本控制系統，用於管理內核源代碼。那麼，開發者該怎麼辦呢？Linus 編寫了每個人都需要但沒人願意開始寫的軟件；他還喜歡以自己的名字來命名事物。據説 Git 首個版本在數週內就寫好了。
CVS
從未聽説過 CVS？Joel Spolsky 於 2000 年 9 月在其同名測試「Joel 的測試」中的第一項，認為 CVS 很優秀。
我曾使用商業源代碼控制軟件，也用過免費的 CVS，我認為 CVS 很好。
是的，打造更優秀軟件的第一步是使用代碼版本控制軟件。（順便説一句，我 1997 年開啓職業生涯時是一名軟件開發人員，並且沒有使用過代碼版本控制，甚至不用 CVS。沒錯，你猜對了：我們只是將 VBScript 文件保存在本地然後通過 FTP 上傳。如果我們互相覆蓋了更改就太糟糕了：人生苦短。直到 2002 年我才第一次使用代碼版本控制系統，那個系統是 Rational ClearCase [小編注：IBM 旗下的產品，簡稱 CC，CC 對於國內互聯網軟件的影響深遠，比如螞蟻集團/支付寶一開始就是採用 CC。後來雖然遷移到了 GitLab，再到內部自研的系統 LinkE，但像 CC 裏的迭代概念，一直就保留了下來，也隨着人員的流動，傳播到了其他公司]。
從未聽説過 Joel Spolsky？他是 Stack Overflow 的聯合創始人，在你的職業生涯中某個時候可能用過這個網站。24 年前，Joel 是新興領域軟件工程中最早的影響者之一。想象更具爭議性的 Kelsey Hightower [小編注：Kubernetes 領域最有影響力的佈道師]，或者觀點不那麼有爭議的 Steve Yegge [小編注：曾經就職於 Amazon, Google, Grab，目前在代碼智能平台公司 Sourcegraph，以公開鋭評公司而著稱]。
説起 Stack Overflow，這裏有一個 2008 年最先進的版本控制技術例子。該網站上的一個早期問題，於 2008.9.8 提出，問到在單個開發者工作流程應該使用什麼版本控制系統。（有趣的是，在現實世界中，同樣時間內爆發了 2008 金融危機。毫無疑問我們行業存在泡沫現象。但我又跑題了）。
我正在嘗試尋找一個對我個人來説盡可能簡單的代碼版本控制工具。我需要的主要功能是能夠閲讀/拉取以前版本的代碼。我是唯一的開發者。
問題的回覆包含了一個長長的目錄，幾乎列出了當時人類所知道的每個版本控制系統。
Odyssey: Windows 版本管理工具
但讓我們回到 2000 年：在 Joel Spolsky 發佈他的「Joel 的測試」之前幾天，Mark Lucovsky 在西雅圖舉行的第四屆 USENIX Windows 系統研討會上發表了一場名為「Windows: A Software-Engineering Odyssey，軟件工程之旅」的演講。Lucovsky 先生是從 1988 年到 2000 年代中期原始 Windows NT 團隊的成員。這次演講的 PPT 至今還可以在線查看，強烈建議去看看。
因為軟件工程之旅的一部分是代碼版本控制。在 PPT 第 14 頁，你可以瞭解到 Windows NT 3.51 使用了一個「內部開發」的系統... 到 Windows 2000 時已經處於「勉強維持生命狀態」：
保持機器同步是巨大的工作量（一週設置時間，每天二小時同步）
額。這不是吸引團隊新成員的好方法。現在你知道為什麼發佈於 2001 年的「敏捷宣言」如此革命性了。多虧 Raymond Chen，可以説他是 Windows 歷史上最重要的講師之一，我們才知道所謂的內部開發系統的名稱：
在早期，微軟使用一個自研代碼版本控制系統，名為 Source Library Manager，通常簡稱 SLM，併發音為 slime。這是一個簡單的系統，不支持分支。
在 Mark Lucovsky 的 PPT 第 24 頁中，我們瞭解到微軟決定將 Windows 2000 的源代碼遷移到一個名為 Source Depot 的東西。Raymond Chen 表示同意：
Windows 2000 發佈後不久，Windows 源代碼轉移到了一個名為 Source Depot 的源代碼控制系統，它是 Perforce 的授權分支。
為什麼選擇 Perforce？這與 Windows 龐大的源代碼庫有關：
原因可能不那麼重要, 但 Perforce 在處理大型存儲庫時往往比 Subversion 表現更好。這也是微軟獲得 Perforce 源碼許可證構建 Source Depot 的原因之一；NT 的存儲庫非常龐大, 並沒有多少產品（無論商業還是其他）能夠處理。
Mark Lucovsky 在他 PPT 第 24 頁上總結了 Source Depot 兩個要點:
新機器設置需要 3 小時 vs. 1 周
正常同步 5 分鐘 vs. 2 小時
微軟 Windows 團隊是否仍在使用 Source Depot？顯然不再如此。在 2017 年，我們得知微軟將所有 300GB Windows 源代碼遷移到 Git，在 Ars Technica 文章中描述另一篇關於 Microsoft 的歷程中提到了版本控制系統:
公司曾經有過一個叫做 SourceSafe 的東西，用它等同於把你全部珍貴的源碼扔進垃圾桶並點火焚燬，因為它會損壞數據庫。
（我可以確認。非常遺憾。）
然而，微軟採用 Git 並非沒有障礙，並因此創建了 Git Virtual File System (GVFS) 項目:
但 Git 不適合處理由 350 萬文件組成、共計 300GB 大小的代碼倉庫。微軟必須着手進行項目定製化以使其能夠應對公司規模需求。
Git 時代
微軟對 Git 的迷戀在 2018 年達到了頂峯，當時它吞併了 GitHub，GitHub 可以説是讓 Git 變得流行了起來。三年前，他們感受到了時代的氣息，併發布了集成 Git 的 Visual Studio Code。
早在 2008 年 2 月，GitHub 就向世界介紹了 Pull Requests 的概念，這一功能後來被 GitLab, Gitea（及其最近的分支 Forgejo）和 BitBucket 採納，並在過去 15 年中成為代碼審核的重要工具。但事實是 GitHub 也在 Git 世界中引發了一個悖論：突然間，一個分佈式源代碼控制系統變得集中化。有些人對此感到不安是可以理解的。
現在是 2024，Git 無處不在。從 2010 年代開始 Git 主導的原因，可以總結為一系列開源軟件的相互取代：20 世紀 70 年代的 SCCS、80 年代的 RCS、90 年代的 CVS 和 21 世紀的 Subversion。想要絲滑的遷移，SVN 可以導入 CVS 存儲庫，Git 可以導入 SVN 存儲庫。但更重要的是版本控制系統已經從類似 SCCS 和 RCS 的僅限本地系統，轉移到了客户端服務器（C/S) 架構 (CVS 和 Subversion)，再到像 Git 和其他系統（尤其是 Mercurial）這樣的分佈式系統。
（談到 Mercurial，火狐最近決定放棄它而改用 Git。）
這些天，我們習慣在計算機上克隆整個項目，之後可以安全地將其斷開網絡並繼續以完全脱機的方式變成。20 年前，這種簡單的範式是完全不可想象的。猜猜看：你本地倉庫還包含了對項目進行的每一次更改的完整歷史記錄。這是一個客户端 - 服務器系統無法提供的特性（劇透警告：服務器擁有完整歷史記錄，而客户端只有 HEAD）。
Git（及其廉價的分支設施）對開發人員工作流程產生了持久影響。Vincent Driessen 於 2010 年 1 月發表了一篇具有里程碑意義的文章「A successful Git branching model，一個成功的 Git 分支模型」，向世界介紹了備受爭議的 git-flow 概念。為什麼會有爭議？因為在軟件行業中大多數觀點都如此。現在已經出現 GitHub flow 和 Atlassian Gitflow workflow 等許多分支工作流程。
Git 倉庫變得富有事件性，在每次推送、合併或標記操作時都會觸發某種工作流程。一個整個行業已經崛起，並涵蓋諸如 Argo CD, GitHub Actions, GitLab CI/CD pipelines 和 Gitea Runner 等名稱，提供了新高度的自動化和便利性。Git 在該領域影響力如此之強大，以至於術語 GitOps 現在指代我們行業中一個完整子集。但你最好別使用分支進行部署。
問題很簡單了：Git 之後會出現什麼？目前來看，挑戰 Git 巨大普及可能是不可能的事情。我説可能，因為在我們行業中預測未來是不可能的事情。值得一提的有兩個有趣競爭者：用 Rust 編寫的 Pijul（儘管該項目十年前始於 OCaml），或由 SQLite 作者編寫的 Fossil 。其二，SQLite 團隊列出過原因，説明為何不使用 Git：
實事求是地説，很少有人會質疑 Git 提供的用户體驗並不理想。許多底層實現都反映在用户界面中。界面如此糟糕，以至於甚至出現了一個惡搞網站，生成假的 git 指令説明書。
在等待更好的替代方案時，讓我們每天閲讀 man 7 giteveryday 頁面，並希望 git-extras, SourceTree, TortoiseGit, Fugitive, Codeberg 和 Magit 可以來解救我們。看起來，無論我們喜歡與否，未來二十年裏我們可能仍然會將源代碼存儲在 Git 存儲庫中。
Hacker News 熱評 🔥
ferd
現在的年輕人不會相信的，直到 21 世紀初，大多數公司使用的代碼版本控制系統（比如微軟的 SourceSafe, ClearCase, Perforce）都會強制你在修改之前鎖定中央倉庫上的所有文件...即使你只是想本地用一個文件進行一些測試也經常如此。。。太瘋狂了。所以，在一個客户現場（我當時正給他們提供諮詢服務），我再也無法忍受了（自 1997 年起我一直在使用 CVS）。於是我安裝了 SVN 來處理他們的項目並展示給了團隊。結果被稱為「不負責任的工程師」...「沒有鎖定就修改文件太瘋狂！真正的工程團隊不這樣做！」
開源世界至少領先 10 年。
ozim
Git 之後會是什麼？
沒有。我無法想象，基於文本的軟件開發目前處於最佳狀態。現在唯一的事情就是 AI，它可以幫助你理清或加快構建代碼。AI 模型都是基於文本的語言，所有低代碼或基於圖像的編程並不適合作為 AI 模型的良好基礎 - 生成圖像顯然無法像生成文本那樣方便地生成用於工作軟件的塊狀圖表。
因此，文本操作將會持續存在，我們可能會有額外工具如 AI 來更快地創建/處理文本，並且 Git 已經是保留文字更改歷史記錄最佳模型了，而且我們需要這個歷史記錄，因為我們仍然需要控制由任何語言描述的複雜系統。
那些認為閲讀和寫作繁瑣麻煩應該消失的人不會改變這種情況。即使神經鏈接到處都有也不能讓信息回寫到大腦中去，所以我認為我們還得長時間依賴閲讀。雖然圖像包含更多信息量，但文字可以非常精確，並且無法僅通過圖像/感覺來描述複雜系統。
vertnerd
想到在二十年後，Github 可能會消失，沒有人再用 Git，這是令人警醒的。我用過很多不同的版本控制系統，從 90 年代開始就用 PVCS。Subversion, CVS, Mercurial 等等其他一些我記不起名字的！我討厭 Git，但我的所有工作現在都存儲在 Github 上。它在二十年後何去何從？
後記
既然 Git 以及 GitOps 已經成了事實標準，那麼作為研發工具就也自然會去擁抱它，這其中也出現了像 GitLab, HashiCorp 這樣的大幾十億美金市值的公司，相互成就。而數據庫開發工具領域的 Bytebase，也同樣提供了業界首屈一指的數據庫 GitOps 方案，可以和諸如 GitLab, GitHub, BitBucket, Azure DevOps 這些主流代碼倉庫 CI 流水線無縫集成。
💡 更多資訊，請關注 Bytebase 公號：Bytebase
