GitHub如何運作：非同步工作

導讀：GitHub公司的職員Zach Holman寫了一篇關於“GitHub如何運作管理”的文章，文章分三部分，這是第二部分：非同步工作。（下面是全文）

這是到目前為止我在GitHub工作最喜歡的方面：每件事都是非同步。

聊天

GiHtub在最初的兩年沒有辦公室。我們用聊天室(Campfire)來溝通。現在我們已經搬到了第二個辦公室，但仍然使用Campfire。這是因為聊天可以是不同步的。

用這種非同步交流方式，我可以出去吃飯，然後當我回來的時候我仍能跟得上對話；我可以問同事一個問題，不用擔心會打擾到她，因為當她有時間的時候她自然會回複；我可以去Minnesota的鄉村，也可以同平常一樣好像在辦公室工作。

Pull Requests

（編註：“Pull Requests”是GitHub上的一種討論形式，有關代碼討論、代碼審查、管理代碼的變化。 Pull Requests = 代碼 + 問題 + 代碼注釋。）

我們的開發工作流程中涉及Pull Requests，我想在以後的部落格中更加詳細的講述這一流程。現在我只想表達我對這種方式的喜愛之情。以前那些需要進行複雜的分支操作的日子一去不複返了，取而代之的是只需要自己對著螢幕查閱代碼的簡潔方式。

如果我想增加一個新功能，或者會修改代碼，我會將代碼push到一個新分支，並且建立一個Pull Requests。如果My Code會影響我同事的代碼，或者他們對My Code感興趣，或者他們時間充裕的話，他們可以查看My Code。這時我們可以將那個分支發布到其他機器上，調試新功能，如果一切正常的話，就可以將這個分支合并到主分支去。

有了Pull Requests的工作方式，我就不需要特別去開個會，方便了每個人。還有個原因：

開會是有害的

37signals在《Getting Real》一書中討論過“開會是有害的”這個主題。相對於37signals，我對於開會的厭惡是有過之而無不及，我討厭開會。

往往你正在忙的時候，就要開會了。他們還經常會請一些不相關的人開會。即使你對會議的主題高度興趣，你也會最終被搞得懊惱。因為開會，你不得不停止手頭的工作，而開會卻是跟你“談論”你正在的工作。開會期望你提前在白紙上設計出完美的系統，而顯然push一個分支，查看diff，基於diff來修改代碼更簡單些。

除此之外，開會的內容很容易被遺忘。即使你做了會議記錄，你也不能保證你能記錄所有內容。有某些你沒有來得及記下來，你想會後再補上記錄。但是三個星期過去了，你回憶起好像某些東西沒有記錄下來，顯然那次討論才是更重要的。如果採用聊天記錄的方式，就不存在這個問題。另外文字溝通的方式也減少了開會時開小差的情況。

我們在GitHub也會開會，但是過去的一年半中開會的次數屈指可數。

最佳狀態

再回到我的上一篇文章：你想要你的僱員處於“最佳狀態”。但是如果他們只能在那種狀態下工作一個小時就要開會了，這將打亂他們。

我們發現，如果讓那些負責任的人按照他們自己的時間來安排工作，他們不僅能完成重要的工作，也能保證其他工作的高效率。