GitHub 的“封神”之路！

2008年，在無數人為代碼協作方式而感到異常頭疼的時候，GitHub 橫空出世，完美契合了市場的迫切需求。自此，它以驚人的速度成長起來並蔓延到全世界，徹底融入開發編程的日常之中。僅僅十年，現在的 GitHub 已經成為開源的事實標準，左右著無數開發者的編程命脈。本文就從最開始的地方，一起來追溯 GitHub 的“封神”之路。

2008年，Tom Preston-Werner、Chris Wanstrath 和 PJ Hyett 三位摯友聚在一起，準備合作開發一個週末小項目。但是沒過多久，他們便意識到這個想法可能比他們預想的要大得多。他們的想法遠不止一個週末小項目那麼簡單，它將徹底改變人們編寫代碼和分享代碼的方式。

這個想法就是 GitHub。

在短短10年間，GitHub 便徹底改變了人們的編碼方式。GitHub 不僅讓編碼變得容易，它還改變了軟件開發人員對編程的看法和理解。

世界範圍內，無數的人都在為代碼協作方式感到頭疼，GitHub 橫空出世，解決了這個疑難問題，並設計出了市場迫切需要的優雅解決方案。以此，它得以驚人的速度發展壯大，取得了巨大的成功。通過圍繞開源項目 Git 構建 SaaS 服務，GitHub 能夠為開源生態系統提供價值並從中獲利。GitHub 對微軟來說充滿吸引力，儘管微軟曾經在開源社區並不顯眼，但它在2018年6月初對 GitHub 進行了收購。

我們一起來看看下列問題：

• GitHub 如何從一個版本控制系統發展為程序員的社交工具，並最終成為在線存放和管理代碼的重要場所？
• 
  
• 為什麼 GitHub 的免費增值模式運行良好，並且能夠如此有效地引領時代？
• 
  
• GitHub 如何抓住了廣闊的潛在市場需求，並圍繞這種需求創造了一種剛需產品？

為了更好地理解 GitHub 的重要性，我們需要回到2008，瞭解當時的軟件開發現狀，以及是什麼造就了偉大的 GitHub。

1、2007-2011：代碼協作與軟件社交

比爾蓋茨和史蒂夫喬布斯從根本上重塑了個人計算機，他們成為家喻戶曉的名人，但我們也完全無法忽視芬蘭軟件工程師 Linus Torvalds 對科技領域的巨大貢獻，他創造了 Linux 操作系統。當時的 Windows 和 Mac 幾乎統治了整個操作系統領域，Linux 操作系統於1991年發佈，它是一個非常靈活、輕量級和安全的開源操作系統，面世之後，很快就受到了想要對系統進行深入控制的極客以及技術人員的青睞。

發明一個全新的操作系統這樣的成就可能對大多數程序員來說都應該感到知足了，但 Torvalds 卻並不滿足，他沒有停下創新的腳步。2005年，Torvalds 推出了他的最新項目：一個名為 Git 的新的版本控制系統。版本控制對編程協作來說至關重要，它需要跟蹤計算機中隨時間變化的文件。它與計算機備份系統用作還原點的“快照”類似，版本控制系統讓程序員能夠通過“fork”或者“分支”來管理項目代碼，程序員在同一個項目工作，但不會影響其他人編寫的代碼。程序員可以在自己的分支上進行開發，之後將新的代碼合併到主項目（也就是代碼倉庫）中。

在 Git 誕生之前，程序員之間進行編程協作的方式很少。其中 Subversion 比較受歡迎，它是一個開源的版本控制系統。它存在著與其他版本控制系統類似的缺點，當然這些缺點是當時的協作編程概念所無法避免的。即使使用了Subversion，與開源團隊合作通常也需要獲得項目管理員的許可才能 fork 項目的一個分支，否則便無法編輯代碼。在許多情況下，批准過程比編寫代碼花費的時間更長。許多開源項目都受到權限問題以及其它一些低效率事情的困擾。

當 Git 於2005年發佈時，開源領域正在經歷一場文藝復興。那時的開發者對 Linux 充滿濃烈的興趣。第一個 Web 2.0 應用程序已經開始出現。許多公司正在將他們的項目遷移到開源服務器。儘管 Git 通過引入 fork 概念使得開源項目的合作變得容易，但 Git 依然有其侷限：它無法幫助開發人員尋找開源項目。許多程序員開發了大量的優秀開源項目，但卻很難讓他人知道這些項目。

GitHub 改變了這一切。

PJ Hyett 和 Chris Wanstrath 在2007年開始討論 GitHub 項目，當時這兩人都是科技網站 CNET 的程序員。他們都支持 Ruby on Rails 開發框架。當他們在 CNET 工作時，Hyett 和 Wanstrath 還為 Rails 的代碼庫提出了一些改進和建議。但是，讓其他人真正查看他們的代碼是另一回事。

正如當時大多數開源項目的典型情況一樣，Rails 的代碼庫由一個小型的、緊密結合的程序員管理，他們手動管理對代碼庫的貢獻。這些程序員扮演者管理員的角色。Hyett 和 Wanstrath 不僅要請求這些管理員查看他們的代碼，還要讓他們相信自己提交的代碼對 Rails 項目是有價值的。即使其中一個項目管理員認為提交的代碼有用，但是補丁的合併也不會很容易。

從本質上講，想要為 Rails 項目貢獻代碼，熟人的爛代碼比陌生人的好代碼更容易通過。

Git 試圖解決其中的一些問題。Linus Torvalds 的版本控制系統與他幾年前單槍匹馬打造的操作系統一樣出色。Git 使得程序員無需管理員開通訪問權限，即可進行編碼協作。Git 是編碼最終民主化的關鍵第一步，特別是在開源社區。但是，儘管 Git 解決了很多問題，但它缺乏協作工具，並且兩個程序員之間共享代碼仍然很笨拙和困難。現在可能很難想象，當時軟件開發人員需要通過電子郵件不斷來回發送補丁，這就很容易理解為什麼迫切需要 GitHub。

遺憾的是，這不是 Git 唯一需要的東西。起初 Git 主要依賴於命令行界面，好在 Git 發佈後很快就推出了圖形界面。對於那些多年來一直在編寫 bash 腳本和正則表達式的系統管理員和其他高級用戶來說，這是個好消息。對於其他人來說感覺倒並不明顯。

“人們開始在 Ruby 會議上談論 Git。主要討論它的好處，但有時也談到缺點。Git 會以分佈式方式處理代碼，但是如何保證共享私有代碼的安全性呢？唯一的選擇是在 Unix 計算機上設置用戶帳戶並將其用作臨時解決方案。這個解決方案並不理想。” — Tom Preston-Werner

儘管存在這些缺點，但 Git 依然充滿潛力，它給來自灣區的 Ruby 程序員 Tom Preston-Werner 來了一些想法。當時 Preston-Werner 正在開發一個名為 Grit 的項目，這個工具讓程序員能夠使用 Ruby on Rails 以面向對象的方式訪問 Git 存儲庫。Preston-Werner 在舊金山一家名為 zeke's 的體育酒吧內舉辦的 Ruby 會議上認識了 Chris Wanstrath，Preston-Werner 把 Grit 告訴了 Wanstrath。

Preston-Werner 的願景是創建一個可以託管整個代碼庫的地方，程序員可以協同工作代碼項目，並瞭解如何充分利用 Git。用 Preston-Werner 的話說，它將是一個“ Git hub（中心）”。

Preston-Werner 和 Wanstrath 於2007年10月1日正式開始製作 GitHub 的第一個版本。在舊金山體育酒吧相識的幾周之後，Chris Wanstrath 提交了第一個 GitHub 版本，從此便徹底改變了編程方式。

當 Preston-Werner 和 Wanstrath 在2007年開始合作時，他們的想法不是將 GitHub 作為商業工具開發並圍繞它開展業務。Wanstrath 和 Preston-Werner 需要 GitHub 來完成他們自己的工作，所以他們開發這個工具是為了滿足自己的剛需。他們很快就發現了他們工作中的一個主要問題：他們需要 fork 代碼分支和協作編程，並設計出滿足他們需求的解決方案。對於這個 Wanstrath 和 Preston-Werner遇到的問題，無論使用哪種編程語言或者操作系統，幾乎所有軟件開發人員都會遇到。這代表了他們的產品在未來擁有巨大的市場潛力。

在接下來的幾周裡，Wanstrath 在週末與 Preston-Werner 會面，共同完成了 GitHub 的第一次迭代。Preston-Werner 主要負責設計，Wanstrath 專注於實現 Preston-Werner 提出的功能。

“在接下來的三個月裡，Chris 和我花了很多時間來規劃和編寫 GitHub。平時我繼續為 Grit 設計 UI。Chris 構建 Rails 應用程序。我們每個星期六都會見面討論設計，並規劃這個產品的藍圖。” — Tom Preston-Werner

2008年1月，經過三個月利用週末時間編寫代碼，GitHub 有點像模像樣了，Wanstrath 和 Preston-Werner 準備向全世界推出 GitHub。正如 Spotify 在其關鍵的早期開發階段所做的那樣，GitHub 首次以私有測試版的形式推出。Wanstrath 和 Preston-Werner 通過向他們在灣區及其他地區的初創公司的朋友發送電子郵件，邀請他們使用他們構建的工具，之後便立即得到了積極的回應。接下來的一個月，他們將 Logical Awesome 改名為 GitHub，Inc，並作為公司正式成立。

雖然這兩個人還沒有開始創業，但他們的想法蘊含巨大的商業潛力。2008年4月，就在 GitHub 推出私有測試版並在同月推出其官方網站的三個月後，Chris Wanstrath 收到了來自在線學習網站 PeepCode 的創始人 Geoffrey Grosenbach 的消息，該網站剛剛將其代碼遷移到了 GitHub。Grosenbach 告訴 Wanstrath 他不習慣使用 GitHub 免費託管他公司的代碼庫，他願意付費。來自活躍的 GitHub 用戶的這類消息展現了 GitHub 的價值。即使 GitHub 沒有向用戶收費，有些人也願意為此付費。

“我使用 GitHub 免費託管我公司的代碼，我對此感到有些不好意思。我可以發一張支票給你們嗎？” - PeepCode 的創始人 Geoffrey Grosenbach

GitHub 發展中最重要的一個因素是其商業模式的簡潔和優雅。如果你想公開託管你的代碼，GitHub 可以永久免費使用。如果你想使用私有存儲庫或專有代碼，你需要付費。這兩個用例完全不同