導讀：Github公司的職員Zach Holman寫了一篇關於“GitHub如何運作管理”的文章，文章分三部分，這是第二部分：非同步工作。（下面是全文）
這是到目前為止我在GitHub工作最喜歡的方面：每件事都是非同步的。
聊天
GiHtub在最初的兩年沒有辦公室。我們用聊天室(Campfire)來溝通。現在我們已經搬到了第二個辦公室，但仍然使用Campfire。這是因為聊天可以是不同步的。
用這種非同步的交流方式，我可以出去吃飯，然後當我回來的時候我仍能跟得上對話；我可以問同事一個問題，不用擔心會打擾到她，因為當她有時間的時候她自然會回覆；我可以去Minnesota的鄉村，也可以同平常一樣好像在辦公室工作。
Pull Requests
（編注：“Pull Requests”是GitHub上的一種討論形式，有關程式碼討論、程式碼審查、管理程式碼的變化。 Pull Requests = 程式碼 + 問題 + 程式碼註釋。）
我們的開發工作流程中涉及Pull Requests，我想在以後的部落格中更加詳細的講述這一流程。現在我只想表達我對這種方式的喜愛之情。以前那些需要進行復雜的分支操作的日子一去不復返了，取而代之的是隻需要自己對著螢幕查閱程式碼的簡潔方式。
如果我想增加一個新功能，或者會修改程式碼，我會將程式碼push到一個新分支，並且新建一個Pull Requests。如果我的程式碼會影響我同事的程式碼，或者他們對我的程式碼感興趣，或者他們時間充裕的話，他們可以檢視我的程式碼。這時我們可以將那個分支釋出到其他機器上，除錯新功能，如果一切正常的話，就可以將這個分支合併到主分支去。
有了Pull Requests的工作方式，我就不需要特別去開個會，方便了每個人。還有個原因：
開會是有害的
37signals在《Getting Real》一書中討論過“開會是有害的”這個主題。相對於37signals，我對於開會的厭惡是有過之而無不及，我討厭開會。
往往你正在忙的時候，就要開會了。他們還經常會請一些不相關的人開會。即使你對會議的主題很感興趣，你也會最終被搞得懊惱。因為開會，你不得不停止手頭的工作，而開會卻是跟你“談論”你正在的工作。開會期望你提前在白紙上設計出完美的系統，而顯然push一個分支，檢視diff，基於diff來修改程式碼更簡單些。
除此之外，開會的內容很容易被遺忘。即使你做了會議記錄，你也不能保證你能記錄所有內容。有某些你沒有來得及記下來，你想會後再補上記錄。但是三個星期過去了，你回憶起好像某些東西沒有記錄下來，顯然那次討論才是更重要的。如果採用聊天記錄的方式，就不存在這個問題。另外文字溝通的方式也減少了開會時開小差的情況。
我們在GitHub也會開會，但是過去的一年半中開會的次數屈指可數。
最佳狀態
再回到我的上一篇文章：你想要你的僱員處於“最佳狀態”。但是如果他們只能在那種狀態下工作一個小時就要開會了，這將打亂他們。
我們發現，如果讓那些負責任的人按照他們自己的時間來安排工作，他們不僅能完成重要的工作，也能保證其他工作的高效率。
第三篇：《GitHub如何運作：創新很重要》
原文：Zach Holman 編譯：伯樂線上 – 唐小娟
【如需轉載，請標註並保留原文連結、譯文連結和譯者等資訊，謝謝合作！】