[[128158]] 

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

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

不過為了協調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的誕生則成為引導全民邁向協作時代的偉大道路。

英文：http://www.infoworld.com/article/2886828/collaboration-software/github-for-the-rest-of-us.html