引言：

“如果你想要了解真正的歷史，你需要回到在打孔卡上進行人工比對的年代。” —— Jim Rootham

在這個為鱈魚編寫傳記都能夠流行的年代，寫一本記錄程序員如何存儲代碼——他們最重要的勞動成果的書一點也不瘋狂。

既然你和我都沒有時間來閱讀或編寫這樣的一本書，我們打算用這篇博客來進行探討。

這是一個重要的問題。

（現在）版本控制產品非常普通而且很流行。

然而，它經歷了幾十年的不斷創新。在這個領域里最聰明的人的努力下，代碼管理變得非常簡單而且有效。

每一步都是那么讓人感到驚奇。

1. 源代碼就是一個文本文件！（20世紀60年代）

現在看來，存儲源代碼和編寫簡單文檔應該是一樣的。但如果你簡單讀一下ASCII的歷史就會知道，即使達成這樣的共識也來之不易。

2. 人們可以手動跟蹤代碼版本！（20世紀60年代）

在沒有軟件的年代，所有事情都要從源代碼開始。

“我工作的第一家公司有一個源碼管理部門。當你把代碼寫好以后，將軟盤交給源碼管理部門一位漂亮女士。他們會及時更新函數庫，用你的磁盤基于公司官方的代碼構建產品交付給客戶。” ——  Miles Duke

3. 你可以為單個文件保留多個版本！（1972，1978）

采用奇特的交錯編織文件格式，SCCS在版本控制領域稱雄了10年之久。

記錄單個文件的從一個版本到下一個之間的變化花費了幾年的時間。“差異文件比較算法”是這個課題最近發表的一篇論文（1976）。

1982年，RCS反向使用diff文件（描述算法原文）打敗了SCCS成為繼任者，并讓評論家大跌眼鏡：

“一起出現的還有帶有反向比較功能的RCS，我認為它非常棒。” —— 無名氏

4. 每個人都可以檢出自己的拷貝！(1982)

在那個時候，人們工作時需要登錄一臺中央大型機并通過它一起工作。采用符號鏈接，RCS可以讓每個人都工作在相同版本的代碼上，而且每個人都有自己的工作拷貝。

“有一個叫做RCS的文件，實際上它十一個鏈接到RCS倉庫的符號鏈接，你可以與其他小組成員一起使用。”  —— 耶魯大學RCS使用介紹

5. 喔！你可以一次給多個文件進行版本控制！（1986）

令人吃驚的是，直到CVS出現之前，版本控制系統都只支持單個文件。當然，你可以使用通配符讓RCS提交多個文件或者標記特定分支。但這些并不是版本控制系統的一部分。

CVS默認會遞歸修改所有文件。突然之間，軟件從單個目錄或文件變成了文本文件的遞歸樹。

雖然由于不具備“原子性”導致實現的產品不盡如人意（后來Subversion在2000年解決了這個問題），但是瑕不掩瑜。

6. 兩個人可以同時編輯同一個文件，并將他們的工作合并在一起！（1986）

20世紀90年代末，我在Creature Labs工作。我們從Visual SourceSafe（商業軟件，微軟公司發布）轉到CVS（開源軟件，由一些嘻皮士發布）。

坦率的講，大家都懷疑CVS能否做到它宣稱的那樣：讓多個人同時編輯同一個文件，并將他們的修改沒有錯誤地合并到一起而不造成其他問題。

在我們開發Creatures 3的時候，SourceSafe的互斥鎖成為了一個大問題。我們當時要添加垃圾搜集功能，這個功能會影響到幾乎所有的代碼。這個時候，我們的首席程序員不得不在周末檢出每一個文件然后進行修改。

1986年的這篇論文記錄下了這個奇跡。當Dick Grune和他的團隊在荷蘭開發一個編譯器的時候，他們遇到了同樣的問題，CVS從此應運而生。

7. 可以在遠程服務器上共享代碼倉庫！（1994）

大多數時候，人們只在一臺機器上使用版本控制。在1986年，人們可以通過RCS的一些版本以及CVS提供的遠程文件共享機制以擁有遠程代碼倉庫。

“假如RCS的某個版本可以通過遠程服務器訪問，那么開發人員就可以在代碼倉庫之外的機器上進行開發了。”  —— Dick Grune

然而，直到1994年TCP/IP協議的引入，這個想法才得以起步。

“直到Cygnus軟件的Jim Blandy和Karl Fogel（這兩位后來成為Subversion項目的主要開發者）為CVS發布了一些補丁，使得CVS客戶端軟件可以通過遠程TCP/IP連接進行訪問，CVS才真正變得無處不在。 ”—— Eric Raymond

8. 免費的開源版本控制主機服務！(1999）

這并不是源碼管理技術的進步，但這的確是一個標志，Internet社區的發展與技術的進步同等重要：

“OSS以及成為歷史，這已經成為一種趨勢。John T. Hall 預見到，如果項目都是在線開發，那么之前開發的版本就在那里。開發平臺服務是一種創新，但是沒有人去做，我們就想‘為什么不呢？’”—— Brian Biles

就像末日狂歡那樣（因為股票的原因），VA Linux把SourceForge帶到了這個世界上。這對新項目是天大的好消息（例如我的TortoiseCVS）。

在當時，在Internet上獲得一臺服務器很困難而且非常昂貴，進行源碼管理和bug追蹤也是如此。這項新服務盡管缺乏商業模式，卻讓無數項目更早地面世。

譯注：OSS：一個綜合的業務運營和管理平臺，同時也是真正融合了傳統IP數據業務與移動增值業務的綜合管理平臺。

9. 沒有主代碼庫，你可以向所有人發布！（2005）

在21世紀頭10年，有一股將版本控制實現完全分布式的潮流。

也就是說，在你本地的機器上存放的是一份完整的代碼歷史，可以輕易地與任何其他拷貝進行分支和合并。順帶說一下，也正是這個特性使得分支和合并變得更加容易。

我并沒有記錄某個第一次發明這種工具，而是按照它產品化以及流行的時間進行統計。鑒于此，將它定在2005年似乎有些不公平。Mercurial和Git發布于2005年4月。

這篇“分布式版本控制風險”（2005年底）介紹了這個革命性的創新。

10. 當你檢出一個fork，你可以讓大家都看到！（2008）

GitHub的成功有很多原因（盡管我之前提到過一些，要講清楚這個問題還是需要單獨寫一篇文章討論）。

關鍵在于，你可能甚至可以將一些自己做的不大的改動提交到別人的公共代碼上。在GitHub之前，一般我們會保存在自己的電腦上。

如今，只需要簡單做一個fork，或者甚至可以直接在瀏覽器上編輯，這樣任何人都可以馬上發現你代碼中的bug。

尾聲

快速回顧一下這幾十年的進展。是的，計算機的發展做出了貢獻。但更主要的是，這些都是人們為更好地協作而貢獻出的聰明才智。

這讓我想到，下一個會是什么？在版本控制領域還會有什么令人驚嘆的事情發生？

推而廣之，同樣的事情會在其它領域發生嗎？

作為核心信息基礎設施，這種巨大的改進能夠最終改善政府、醫療、新聞或者數據領域創新的障礙嗎？

我有這種感覺，我們就要找到答案了。

想了解更多嗎？請閱讀《版本控制時間軸》（發表于Plastic SCM的博客，不要忘記看一下評論）以及《理解版本控制系統》