關于Git的主要維護者濱野純的訪談
日文原文：Gitメンテナ 濱野純：小飼弾のアルファギークに逢いたい?
上一篇文章中提到，最近正在閱讀《入門 Git》，搜索作者濱野純相關信息的時候搜到了以下這篇著名博客作家小飼彈對濱野純的訪談，里面提及了濱野純當初參與 Git 項目時的軼事，以及他對于開源項目的看法。特別是濱野純說“Git 是他第一次有一定規模地向開源項目提交代碼”，很是鼓舞人——對那些想參與開源項目但缺乏信心的同學。所以趁閑把訪談全文翻譯了一下。
今天我們的嘉賓，是分布式版本管理系統 Git 的主要維護者，同時也是《入門 Git》一書的作者，濱野純先生。而這次的訪談，也從濱野先生談自己從 Linux 內核的開發者，Linus Torvalds 手中接過 Git 維護工作的原委開始了。
結識 Git 的經過
小飼彈（以下簡稱彈）：當初是因為什么原因參與 Git 了的開發呢？
濱野純（以下簡稱濱）：2005 年 4 月起 Linux Kernel 所使用的版本管理系統 BitKeeper 就因為 Licence 關系無法繼續使用了，所以 Linus 考察了很多當時的版本管理系統，但認為沒有一個是能用的。于是他在郵件列表里發了一封郵件，說自己寫了一些代碼，準備作為在找到更好的版本管理系統之前的 過渡系統。而我看到那封郵件時，正好是我的本職工作處于舊項目剛剛完成而新項目還未上馬的間歇時期。我覺得這似乎是件挺有意思的事情，于是就把代碼下載了 下來，看了一下發現只有 1244 行。
彈：全部都是C代碼嗎？
濱：是啊。這點代碼量我估計 2 小時左右應該就能讀完了。仔仔細細地讀了一遍以后，被代碼所表現出來的優美折服了。基本上我不算是一個 Kernel 開發者，Kernel 郵件列表也只是偶爾看一眼的程度而已。但是，如果說參與數十萬行的 Kernel 開發確實有點困難的話，參與這個尚且才 1000 多行代碼的項目應該會很有趣，這算是當初參與 Git 的動機之一。那時候，在一周時間內發生了很多事，不過歸納起來就是 Linux 的內核開發者們聽說 Linus 要用個“新玩意”來管理代碼，如果那個“新玩意”太難用的話大家都痛苦，還不如一起想辦法把這個東西做好用點。而我也得以在開發中觀察這個項目的進展，思 考這個新系統真正需要的是什么等等，總之最后完成了提交 commit 的功能和輸出 diff 的功能。不過，merge 功能還沒有完成。雖然 Linux 當時發過好幾封郵件，描述他理想中的 merge 應該是怎樣的。
彈：Linus 對既往的版本管理系統，最不滿的就是這方面吧。
濱：因為 Linus 只寫C和 Shell，而 merge 的邏輯實在太復雜，所以他多次發郵件到郵件列表，說要是有人能夠用腳本語言實現一個就好了。不過誰也沒有上鉤。就這么過了一個星期，一直關注郵件列表的我 用 Perl 把 Linus 過去多次提到的 merge 算法實現并投到了郵件列表里。這是我第一次有一定規模地向開源項目貢獻代碼。然而，盡管我詳細地寫了將近 30 個測試用例以及各種分支條件下應該怎么處理的表格，6 個小時以后 Linus 提交到 master 分支的卻是個截然不同的東西。據本人說是想到了更好的辦法所以就這么著了。我看了一下，確實就像哥倫布的雞蛋一樣——足以讓我那些依照 Linus 以前的邏輯所寫的代碼毫無價值——就是優雅到這種程度。不過之前你還說什么“誰來幫忙做一下啊”我做了結果你又不要（笑），然而當時并沒有這么想，因為新 的處理方法確實很漂亮。
哥倫布的雞蛋
彈：為什么說是哥倫布的雞蛋呢？
濱：我雖然沒有使用過 BitKeeper，不過 BitKeeper 的做法是在 work tree 里基本上只存放自己的文件，而 merge 不發生在這里。merge 時首先會創建一個臨時文件夾，在里面展開 merge 結果，發生沖突時就在里面解決，然后提交 commit 并在 work tree 里展開，這樣就算 merge 完成了。最初 Git 也準備使用相同的流程，不過解決了沖突以后的代碼，commit 前想測試一下也是人之常情。所以我們就想那不如不要臨時文件夾，直接在 work tree 上 merge 就行了…。Git 在提交 commit 之前，不是有個記錄了本次 commit 內容的 index 嗎？對于這個 index，當初提出了引入分步驟（stage）的概念。也就是說，本來所謂3-way-merge 就是，首先我們有一個共同的版本，你在這個版本的基礎上做了一些變更，我在這個版本的基礎上做了另一些變更，然后將這兩個差分 merge 起來。那么把這三個版本分別作為 stage1，stage2，stage3 依次添加到 index 里，那 merge 不就完成了嗎——Linus 當時就是提出了這樣的建議。仔細想想這種做法確實可以一下子解決很多問題。例如最簡單的情況，我和你都沒有做出變更，那么 merge 的結果就是沒有變更。如果我做了變更而你沒有，那么最后得到的就是我變更以后的代碼，反之亦然。另外還有一種特殊的情況，就是你和我都做了“相同”的變 更。
彈：這種事經常有啊（笑）。
濱：實際使用過以后發現確實如此，特別是 Linux Kernel 的開發，是基于郵件列表的。所以常有你我看到同一個 patch，因為自己使用的版本是 fix 對象于是各自都打上了這個 patch。這種情況也能在 index 中解決，不僅效率很高，結果也很清晰。
Linus 的管理才能
濱：Linus 常說，項目維護者的一半工作就是說 No。不過即便如此，在拒絕別人提交的 patch 的時候，他總會向提交者強調，拒絕是因為這個提交不行，而不是你的能力不行。他對每個貢獻者都很看重。我那時候也是，Linus 對我說，雖然你的提交沒有采用，但測試用例還是能用的，針對現在的實現你稍微修正一下吧。
彈：挺不錯啊。
濱：讓對方覺得自己的工作沒有白費，這樣就不會打擊貢獻者的熱情。不僅提出新的 merge 算法很厲害，Linus 作為社區管理者的才能也很厲害。不服不行啊（笑）。
GitHub
彈：GitHub 和 Git 有組織上的聯系嗎？GitHub 不是 Git 社區的人，而是 Git 愛好者做的嗎？
濱：這個關系說來復雜了。GitHub 的創始人都是 Git 社區以外的人。那些人基本上算是 Ruby 的人吧。Ruby 社區開始大量使用 Git 應該是 Rails 采用 Git 作為版本管理以后的事。GitHub 最初在還沒有像現在這樣流行之前，曾經采用邀請制試運營過一段時間，但是 Git 社區的主要成員卻都沒有收到邀請。雖然我個人不很在意，不過有些人覺得 GitHub 那群人在拿 Git 商業化所以很不爽，結果很長一段時間兩個社區之間不怎么和睦。
彈：Git 和 GitHub 是這種關系啊（笑）。都不很看重對方。
濱：經常會有無視對方自顧自地開發這種事，就比如官方 Git 和 GitHub 的 Git 的 daemon 程序在某些地方是不同的。GitHub 做了一些他們自己的改動。面向大量用戶做出這種非官方的版本，作為 Git 社區也很苦惱啊。
彈：是啊。
濱：然后呢，去年1有 一個 GitTogether 的活動，Google 提供了場地，一共進行了三天吧，GitHub 和 Git 社區的主要成員都來了，探討了今后的發展方向，現在兩個社區的關系應該沒有過去那么差了。事實上，你也覺得 GitHub 的幫助文檔很不錯吧。有 GitHub 替我們做文檔以及用戶支持，何樂而不為呢。
彈：因為過去什么經驗都沒有的人也可以在 GitHub 上直接 fork 項目是吧。確實這種方式我覺得足以改變世界。從一開始就不僅是公開代碼…。
濱：大家一起做一個項目，然后互相 merge，這種工作流程很不錯。
彈：我也是，如果沒有 GitHub 的話也不會知道 Git。
濱：是的，那是非常新穎的方式。盡管有些小地方很希望能夠改一下，但是 GitHub 在普及 Git 上功不可沒。
彈：就是看到了它，才終于明白為什么 Linus 不滿足于過去的版本管理系統了。（那些過去的版本系統）都沒法 merge 嘛。說到底，對于 Linux Kernel 這種巨型的項目來說，或許 merge 這個分支的代碼還是那個分支的代碼會是一個大問題，但是對于普通的項目，只要考慮是取還是舍，維護也基本只需要一個人就足夠了，再不濟還可以分成多個子項 目多人維護，至今為止我們都是這么過來的，所以很難理解 Git 的好處。而 GitHub 的用戶時不時地就會碰到“那個分支再不 merge 就要出問題了”的狀況，切身體會了 merge 的重要性。我覺得那非常好。
優秀程序員的品質
彈：你覺得“優秀的程序員”是怎樣的一種人呢？
濱：當初接手 Git 項目時，Linus 曾說過一個明星程序員有三種品質。最重要的第一點是，能夠持之以恒地做某件事。從這個角度上來說，AlphaGeek2是不行的。盡管對于新事物迅速投身進去不是壞事，但同時又迅速地失去興趣就不好了。順便我自己不那么激進不是新事物愛好者也不會三分鐘熱度，應該不算是 AlphaGeek。
彈：原來如此，三分鐘熱度是不行的。重要的是堅持。
濱：第二點算是審美觀吧。擁有良好的直覺和品位，這是 Linus 的原話。良好的直覺，這里是指面對一個新問題時，即使沒有完整地解決問題也能夠憑直覺提出正確的解決思路和方向。第三點是溝通能力。 這個溝通能力不是說只要說明“我想做什么”就可以了，而是能夠解釋“我的目標是什么”以及我得出這一目標的整個思維過程，并且更重要的，是能夠讓其他人信 服，簡而言之就是能夠將自己的目標明確傳達給他人的人。我覺得這非常重要。即使在 Git 社區內，非常優秀的人至少也有7、8 人，但能夠同時兼具這三點的人非常之少。
彈：雖然之于審美觀我有很多想對 Linus 說的（笑）。不過我也猜得到 Linus 會怎么反駁所以我還是作罷吧。話說回來，這三點中能夠做到其中兩點的人，估計在哪兒都會很吃香吧。做到一點就可以說工作能力很強，做到兩點就可以稱之為牛人了。
濱：說的是啊。Linus 是按照我上面所說的順序提出的這三點，從 Git 社區至今為止的發展過程中來看，我覺得即使是只具備其中一點的人，只要鍛煉一下溝通能力，就能做任何自己想做的事了。溝通能力就是，即使自己做不到，只要 把目標向其他人說明清楚了，就一定會有人來幫你達成這個目標。就是說只要表達想法可以不用非得自己動手。
彈：我在還沒有 Open Source 這個詞的時候就已經算混開源界了吧，不過近幾年來，開源界的表達能力真是越來越高了。拿十年前來和現在比，現在的年輕人的表達能力實在不一般，不是最近流 行 Lightning Talk[^3]嘛，就是 5 分鐘的演講。要是換作以前，肯定得花上 30 分鐘絮絮叨叨才行，但是那些年輕人證明縮短到 5 分鐘內是完全沒有問題的。實際在與他人合作的過程中，過去是做出了產品原型和對方討論這么做如何，而現在則相反，不需要做出實際的成品，只要把想法提出來 就可以了。都是因為現在的工具發達了啊，網絡速度變快了，應用平臺也變好了。有這么一句老語，“現在的年輕人啊真是……”，我想說的是“真是很厲害”。我 甚至都想表揚一下依然能夠跟上這些年輕人腳步的自己了（笑）。現在已經是半年不看項目就跟不上的時代了。覺得 Git 很難，或許也是因為我老了吧（笑）。
對 40 歲以上的程序員說的話
彈：有什么想對 40 歲以上的程序員說的話嗎？40 多歲的程序員，已經漸漸感到追趕年輕人有點吃力，對他們有什么建議嗎？雖然我想說的是，那就趁 20 多歲正年輕的時候多寫點代碼吧。
濱：要怎樣才能成為年輕人的楷模，這個問題很困難啊。
彈：至少有一點，我覺得應該做到的，就是依然覺得寫代碼很快樂。如果抱著受罪的心態寫代碼，那一定是做不好工作的。這么說來，您今年幾歲？
濱：保密（笑）。
彈：至少不是 20、30 歲了吧。我覺得還是挺厲害的。在版本管理系統中 Git 最年輕，但現在卻正漸漸成為主流。
濱：是啊。
彈：年輕的項目不一定只有年輕人在做，我覺得這非常好。
至此全文完。最后附一張大叔的帥氣照片。
左為小飼彈先生，右為濱野純先生。