引言：“如果你想要了解真正的歷史，你需要回到在打孔卡上進行人工比對的年代。” —— 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的部落格，不要忘記看一下評論）以及《理解版本控制系統》（作者Eric Raymond）
打賞支援我翻譯更多好文章，謝謝！
打賞譯者
打賞支援我翻譯更多好文章，謝謝！
任選一種支付方式
