GitHub：超越開發者、走向全民的偉大道路

Git的出現讓來自不同團隊的程式設計師們得以實現協調分散式工作——如今GitHub則將每一位普通民眾走上同樣的協作道路。

軟體開發人員之所以能夠在分散式協作領域一直扮演著先行者的角色，原因在於他們的工作成果一直以數字化形態體現。而隨著網路黎明時代的全面鋪開，他們的工作流程也開始走上聯網道路。

幫助軟體開發人員實現協作的各類工具加上圍繞此類工具所構成的文化理念，當然也希望能夠融入主流體系當中。遙想當年，電子郵件與即時訊息——二者同樣是在接觸普通大眾之前，首先由開發人員廣泛使用——也曾經扮演過同樣的角色並面臨類似的狀況。不過時至今日，這些通訊模式早已走入了尋常百姓家。

不過為了協調Linux核心開發而誕生的工具Git與圍繞該工具所衍生的文化體系GitHub，目前尚未表現出同樣積極的關聯態勢。大多數非開發人士並不依靠編碼作為謀生手段。但隨著各個行業、各個領域的工作成果與流程逐步走上數字化方向，很多普通人同樣會為這些共享式工具所吸引、並藉此實現共享式數字化成果的協調式構建。有鑑於此，Git與GitHub才能夠在程式碼之外、融入更多工作成果的實施流程當中。

根據Wired、ReadWrite以及其它多家站點的報導，GitHub目前已經被用於實現食譜、樂譜、書籍、字型、法律檔案、課程與教程以及資料集等資源的協作開發管理。考慮到Git本身令人望而生畏的複雜性，以上狀況無疑有些匪夷所思。

原因之一在於GitHub利用其Web介面逐步提供更多底層Git功能。另一項理由則是，更多Web應用程式開始利用GitHub作為其執行平臺。接下來再看文化方面的因素：GitHub帶來了一種特殊的協作途徑。Dave Winer將其形容為“個人工作述職”階段。我個人則用“看得見的工作”進行描述。Responsive Organization活動為其“隱私之上的透明性”而歡欣鼓舞。在GitHub管理體系內部，倡導者Ben Balter也以“開放式協作”對其加以盛讚。

在一篇尚未正式發表的博文中，我讀到了Ben Balter就這一觀點的說明。而自從該博文被託管在公共GitHub庫中之後，我除了查閱文章的草稿之外，還對審查意見以及圍繞該草稿展開的探討內容進行了高度關注。當然，單單一套庫並不一定需要向公眾開放——但每一家企業都應當鼓勵將開放協作機制引入內部業務流程。根據GitHub發展戰略副總裁Brian Doll的觀點，目前已經有越來越多企業對這種共享式機制表現出深厚興趣。

人們常說，時至今日每一家企業都可算作是軟體廠商。從抽象角度來看，這種說法並無不可——只要大家將智慧財產權也定義在軟體範疇之內。而且對於不少企業來說，其真正業務價值也確實體現在內部開發的軟體成果身上。

企業始終期望著能夠將這種協作式發展機制在程式碼、測試、質量保證以及說明文件等傳統領域之外加以進一步擴充。不過如果此類協作機制的貢獻成果完全取決於我們自身對於業務或者客戶的理解，那麼大家可能很難直接參與進去。

“這太瘋狂了，”Brain Doll表示。“如果大家在銀行中擔任管理者角色，那麼員工及客戶所使用的財富管理工具也就成為銀行提供的產品——他們怎麼可能直接參與此類方案的改進工作？”但在GitHub的幫助下，每一位股東都能夠成為一流的參與者。相較於僅僅用於記錄系統運作狀態的電子郵件，他們還可以傳送各類請求並直接在系統當中討論相關問題。

馴服Git這隻猛獸

作為GitHub引擎蓋之下控制引擎的分散式版本，Git的運作方式不僅能夠給非程式設計師帶來驚喜、更能讓普通程式設計師們通過集中化系統對其實現訪問。

在此類系統當中，於庫內部建立一套分支可謂非同小可，其作用相當於一系列既有成果的備用版本。在Git當中，一套分支就相當於一套輕量級構建成果、一種通過移動指標而非資料所產生的嘗試預期。在傳統系統當中，即使僅僅是為了變更文件中的每個字句而構建的分支都會帶來高昂的實現成本。但Git卻讓這種機動性變得物美價廉。GitHub能夠將其嵌入到工作流程當中——即獲取到的請求——流程會對變更內容加以封裝，而後將其與文件的變更歷史相結合。

Git的這種千變萬化的能力使其成為工作流程創新領域的理想實驗環境，但可供選擇的實現方式過多也帶來了新的複雜性層。分支與合併機制雖然足夠強大，但技術人員仍然在面對何時以及如何進行分支與合併操作時分裂成了各種派別。這一切都給程式設計師提出了嚴峻挑戰，而且這種挑戰要遠比其它麻煩更難於解決。有鑑於此，我們如何才能馴服這隻猛獸，從而保證非技術出身的利益相關者也能享受到它所帶來的便利？

GitHub給出的答案是：強化網站本身以實現各類核心操作。如果一位律師希望修改法律檔案中的個別字句，她根本不必接觸恐怖的Git客戶端; 她完全能夠通過瀏覽器直接實現檔案編輯。這種操作將啟動一項pull request流程，其會針對特定變更建立出新的分支。GitHub使用者總愛說“實現變更只有惟一一種方式。”雖然不是每個人都必須遵循這種黃金定律，但選擇最簡實現辦法無疑能大大減少工作中遇到的阻力。

這樣一來，只要企業願意接納GitHub、那麼每一位員工都能輕鬆實現這種最佳實踐。“不要在發現軟體問題時盲目指責水冷機制不夠給力，”Brain Doll提醒道。“現在大家已經有辦法對自己瞭解範圍內的問題加以修正。”這種鼓勵人們參與進來的機制對客戶也同樣有效。

GitHub自身的變更同樣至關重要。“如果不切身參與進來，”Software Carpentry專案創始人Greg Wilson指出，“我根本沒辦法搞清楚GitHub的許可權管理機制、允許使用者針對單一repo製作多種fork或者完成其它類似的工作。”

不過無論GitHub風格的互動方案如何具體起效，變更機制都能確切發揮作用——而無需擔心針對單一變更的貢獻內容到底屬於程式碼、文件、法律建議、企業立場抑或是客戶反饋。

作為GitHub當中最為重要的創新成果，溝通與共享的核心價值在引入其它社交媒體中的交流內容之後得到了進一步增強。舉例來說，大家可以在Twitter上通過提及另一位Twitter使用者的使用者名稱來引起對方的注意。這種@提及技術在GitHub當中也同樣為個人及團隊作出了巨大貢獻。

GitHub Pages同樣不可不提，這項服務負責託管GitHub庫之上的入口網站。對於熟悉Git並樂於安裝（並以本地方式使用）基於Ruby的站點生成工具——也就是Jekyll——的技術型博主來說，GitHub Pages絕對是他們的心頭最愛。不過也有使用者發現，我們並不一定需要安裝Jekyll。大家完全可以直接在瀏覽器當中管理GitHub Pages，同時享受版本歷史以及問題討論功能所帶來的便利。

讓變化變得視覺化

版本控制與變更視覺化機制已經深深植根於軟體開發領域當中。時至今日，已經沒有任何元件開發人員會考慮在無法通過“diff”進行變更內容說明的前提下討論新版本中的某些程式碼。

大多數知識型員工並不具備這種非對等性分佈預期。雖然在企業當中這種數字化技術認知應當成為基礎性素養，但實際上其並未真正得到普及。而這也種障礙也同時影響到文化（‘我們之前從沒采取過這樣的方式’）以及技術（‘我的工作成果並不是什麼文字檔案’）層面。

軟體開發所產生的數字化成果仍然體現為包含有文字內容的檔案，而且其實質能夠追溯至原始的打孔卡載體。我們也仍然需要一行一行對這些檔案的內容在視覺基礎上進行修改。編譯器與IDE能夠從模組以及方法的角度瞭解程式碼內容，但版本控制系統並不會分享這種認知結果。雖然從理論角度講，利用計算裝置將變更抽象理解為模組X或者方法Y、並隨時間推移持續觀察此類變更聽起來完全可行，但在現實當中卻並非如此。

這種理論與現實之間的不匹配狀況源自多種深層次歷史原因，而且在短時間內不可能很快得到扭轉。與此同時，我們可以通過兩種方式解決這一難題——而GitHub恰恰在這兩方面都有所建樹。

方法之一在於將富文件轉換為文字檔案。在政府機構當中這是一種常見的實踐方式，其中GitHub則扮演著協作平臺的角色，Ben Balter指出。他還建立出一款工具，能夠將政府內部廣泛使用的Word文件轉化為Markdown——一種能夠在GitHub以及其它多種環境下使用的純文字格式。這種變通方案還遠遠稱不上理想方式，這主要出於兩點原因。其一，對文件格式進行往來轉換通常存在風險——而Markdown並不屬於標準化格式。其二，其中包含多種變數; 事實上，GitHub所使用的準確來說應該是Git Hub Flavored Markdown。

從理想角度看，GitHub應當能夠直接處理富文件格式，其在這方面也確實取得了一定進展。我們長久以來早已能夠以視覺化方式對不同影像中的差別作出對比。一年之前，“prose diff”能夠將不同Markdown檔案內HTML渲染內容之間的差別以彩色方式進行高亮顯示。這種方式同樣也能用於著重體現CSV資料以及HTML表間的差異部分，但卻並沒能在文件結構識別方面做出更多貢獻。

此類識別能力如今在一種格式當中成為現實，這就是GeoJSON。它能夠將地理空間資訊以JSON格式進行編碼，而GItHub除了可以利用其作為資料渲染手段之一顯示地圖之外，也能夠利用滾動滑塊在不同版本之間顯示該地圖的直觀版本變更歷史。如果能夠將這種方式推廣到Word文件、PDF檔案以及電子表格當中，那麼GitHub類協作機制將幫助更多使用此類格式構建產品的人們加入到這個大家庭當中。

GitHub即平臺

對於由其託管的數百萬專案而言，GitHub並不能滿足全部需求，但它允許人們在此基礎之上構建成果並將成果融入當中。使用GitHub API的工具承載著大量來自現有庫的專案管理功能，其中包括Waffleio、HuBoard以及ZenHub等等。

像Travis以及Jenkins這樣的持續整合系統能夠使用狀態API報告與提交內容相關的測試結果。此外，CRUD API則讓程式設計型提交內容得以在庫當中實現檔案的建立、更新或者刪除操作。舉例來說，Ben Balter就曾經利用它構建過一款應用程式，旨在從HTML格式內獲取輸入資訊、並將其附加在GitHub庫中的CSV檔案當中。

當然，GitHub並不是一套適用於每位使用者的平臺。O’Reilly媒體的Atlas——一套用於釋出多種書籍格式的託管系統——就直接建立在Git基礎之上。不過對於多數非長久使用Git的用例而言，GitHub的介面——以及不斷進化的擴充套件成果——必將成為一套強有力的綜合體。

協作的文化

與Git類似，GitHub也成為多種協作方式的立足根基。GitHub鼓勵各類關鍵性最佳實踐，例如在不干涉其它來源的前提下通過一次性分支實現pull request提交。而標籤則作為配發給提交內容及pull request的關鍵詞。（其它社交系統可能會呼叫這些標籤，但Git標籤會識別庫歷史當中的特定點。）大家用不著強行使用標籤機制，但一旦接觸——如果大家的團隊採用了詳盡且具備高度一致性的用詞——那麼由此產生的過濾檢視將幫助每個人快速瞭解專案的概貌。

建立實用的提交資訊則是另一種促進協作活動的有效途徑。程式設計師往往會在提交資訊當中發揮幽默感，例如“我修改了一部分內容”，並通過多年的實踐經驗學會了如何及為什麼要更為高效地對工作內容進行闡述。不過大部分知識型員工並不會用這種格式化的小型單位劃分自己的工作成果、將其廣泛共享至空間中並以有意義的方式提供他人可資借鑑的描述內容。

這些實踐方式全部基於一項共識性結論，即所有共享成果都應當進行版本區分，而全部變更也都需要經過嚴格控制並配備文件記錄——這種最佳實踐絕不應被僅僅限制在軟體開發領域當中。我們都在以分散式方式處理日常工作，因此需要審慎配合、關注細節並培養團隊意識。Git為程式設計師們開啟了通往無限希望的廈門，而GitHub的誕生則成為引導全民邁向協作時代的偉大道路。