[分享] 濱野純訪談：為什麼 Google 接管開發 Git 2.0 了？

導讀：最近 Google 推出了 Git 協議的 2.0 版。我們都知道 Git 是的 Linus 開發實現的。估計大家會有點好奇，為啥是 Google 「接管」了。目前 Git 的主要維護者濱野純是一位 Google 工程師。
濱野純是如何接手 Git 維護任務的？推薦大家往下看這篇訪談。

今天我們的嘉賓，是分布式版本管理系統Git的主要維護者，同時也是《入門Git》一書的作者，濱野純先生。而這次的訪談，也從濱野先生談自己從Linux內核的開發者，Linus Torvalds手中接過Git維護工作的原委開始了。

結識Git的經過

小飼彈（以下簡稱彈）：當初是因為什麼原因參與Git了的開發呢？

濱野純（以下簡稱濱）：2005年4月起Linux Kernel所使用的版本管理系統BitKeeper就因為License關系無法繼續使用了，所以Linus考察了很多當時的版本管理系統，但認為沒有一個是能用的。于是他在郵件列表里發了一封郵件，說自己寫了一些代碼，準備作為在找到更好的版本管理系統之前的過渡系統。而我看到那封郵件時，正好是我的本職工作處于舊項目剛剛完成而新項目還未上馬的間歇時期。我覺得這似乎是件挺有意思的事情，于是就把代碼下載了下來，看了一下發現只有1244行。

彈：全部都是C代碼嗎？

濱：是啊。這點代碼量我估計2小時左右應該就能讀完了。仔仔細細地讀了一遍以後，被代碼所表現出來的優美折服了。基本上我不算是一個Kernel開發者，Kernel郵件列表也只是偶爾看一眼的程度而已。但是，如果說參與數十萬行的Kernel開發確實有點困難的話，參與這個尚且才1000多行代碼的項目應該會很有趣，這算是當初參與Git的動機之一。那時候，在一周時間內發生了很多事，不過歸納起來就是Linux的內核開發者們聽說Linus要用個“新玩意”來管理代碼，如果那個“新玩意”太難用的話大家都痛苦，還不如一起想辦法把這個東西做好用點。而我也得以在開發中觀察這個項目的進展，思考這個新系統真正需要的是什麼等等，總之最後完成了提交commit的功能和輸出diff的功能。不過，merge功能還沒有完成。雖然Linus當時發過好幾封郵件，描述他理想中的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社區也很苦惱啊。

彈：是啊。

濱：然後呢，去年有一個GitTogether的活動，Google提供了場地，一共進行了三天吧，GitHub和Git社區的主要成員都來了，探討了今後的發展方向，現在兩個社區的關系應該沒有過去那麼差了。事實上，你也覺得GitHub的幫助文檔很不錯吧。有GitHub替我們做文檔以及用戶支持，何樂而不為呢。

彈：因為過去什麼經驗都沒有的人也可以在GitHub上直接fork項目是吧。確實這種方式我覺得足以改變世界。從一開始就不僅是公開代碼…。

濱：大家一起做一個項目，然後互相merge，這種工作流程很不錯。

彈：我也是，如果沒有GitHub的話也不會知道Git。

濱：是的，那是非常新穎的方式。盡管有些小地方很希望能夠改一下，但是GitHub在普及Git上功不可沒。

彈：就是看到了它，才終于明白為什麼Linus不滿足于過去的版本管理系統了。（那些過去的版本系統）都沒法merge嘛。說到底，對于Linux Kernel這種巨型的項目來說，或許merge這個分支的代碼還是那個分支的代碼會是一個大問題，但是對于普通的項目，只要考慮是取還是舍，維護也基本只需要一個人就足夠了，再不濟還可以分成多個子項目多人維護，至今為止我們都是這麼過來的，所以很難理解Git的好處。而GitHub的用戶時不時地就會碰到“那個分支再不merge就要出問題了”的狀況，切身體會了merge的重要性。我覺得那非常好。

優秀程序員的品質

彈：你覺得“優秀的程序員”是怎樣的一種人呢？

濱：當初接手Git項目時，Linus曾說過一個明星程序員有三種品質。最重要的第一點是，能夠持之以恒地做某件事。從這個角度上來說，AlphaGeek【見文末注1】是不行的。盡管對于新事物迅速投身進去不是壞事，但同時又迅速地失去興趣就不好了。順便我自己不那麼激進不是新事物愛好者也不會三分鐘熱度，應該不算是AlphaGeek。

彈：原來如此，三分鐘熱度是不行的。重要的是堅持。

濱：第二點算是審美觀吧。擁有良好的直覺和品位，這是Linus的原話。良好的直覺，這里是指面對一個新問題時，即使沒有完整地解決問題也能夠憑直覺提出正確的解決思路和方向。第三點是溝通能力。這個溝通能力不是說只要說明“我想做什麼”就可以了，而是能夠解釋“我的目標是什麼”以及我得出這一目標的整個思維過程，并且更重要的，是能夠讓其他人信服，簡而言之就是能夠將自己的目標明確傳達給他人的人。我覺得這非常重要。即使在Git社區內，非常優秀的人至少也有7、8人，但能夠同時兼具這三點的人非常之少。

彈：雖然之于審美觀我有很多想對Linus說的（笑）。不過我也猜得到Linus會怎麼反駁所以我還是作罷吧。話說回來，這三點中能夠做到其中兩點的人，估計在哪兒都會很吃香吧。做到一點就可以說工作能力很強，做到兩點就可以稱之為牛人了。

濱：說的是啊。Linus是按照我上面所說的順序提出的這三點，從Git社區至今為止的發展過程中來看，我覺得即使是只具備其中一點的人，只要鍛煉一下溝通能力，就能做任何自己想做的事了。溝通能力就是，即使自己做不到，只要把目標向其他人說明清楚了，就一定會有人來幫你達成這個目標。就是說只要表達想法可以不用非得自己動手。

彈：我在還沒有Open Source這個詞的時候就已經算混開源界了吧，不過近幾年來，開源界的表達能力真是越來越高了。拿十年前來和現在比，現在的年輕人的表達能力實在不一般，不是最近流行 Lightning Talk【見文末注2】嘛，就是5分鐘的演講。要是換作以前，肯定得花上30分鐘絮絮叨叨才行，但是那些年輕人證明縮短到5分鐘內是完全沒有問題的。實際在與他人合作的過程中，過去是做出了產品原型和對方討論這麼做如何，而現在則相反，不需要做出實際的成品，只要把想法提出來就可以了。都是因為現在的工具發達了啊，網絡速度變快了，應用平臺也變好了。有這麼一句老語，“現在的年輕人啊真是……”，我想說的是“真是很厲害”。我甚至都想表揚一下依然能夠跟上這些年輕人腳步的自己了（笑）。現在已經是半年不看項目就跟不上的時代了。覺得Git很難，或許也是因為我老了吧（笑）。

對40歲以上的程序員說的話

彈：有什麼想對40歲以上的程序員說的話嗎？40多歲的程序員，已經漸漸感到追趕年輕人有點吃力，對他們有什麼建議嗎？雖然我想說的是，那就趁20多歲正年輕的時候多寫點代碼吧。

濱：要怎樣才能成為年輕人的楷模，這個問題很困難啊。

彈：至少有一點，我覺得應該做到的，就是依然覺得寫代碼很快樂。如果抱著受罪的心態寫代碼，那一定是做不好工作的。這麼說來，您今年幾歲？

濱：保密（笑）。

彈：至少不是20、30歲了吧。我覺得還是挺厲害的。在版本管理系統中Git最年輕，但現在卻正漸漸成為主流。

濱：是啊。

彈：年輕的項目不一定只有年輕人在做，我覺得這非常好。

至此全文完。最後附一張大叔的帥氣照片。

左為小飼彈先生，右為濱野純先生。

來源：http://www.techug.com/post/why-google-develop-git-2-0.html

＃＃

您可能也會有興趣的類似文章

• Git的Staging Area的中文翻譯探討 (2則留言, 2014/09/12)
• [Batch#3 Git#3] 如何在Windows批次檔裡將提示字元變更為Git分支名稱？ (初學者的命令行 #7) (0則留言, 2020/01/05)
• 將Git分支名稱加到提示字元（Prompt）裡 (0則留言, 2014/09/02)
• [Git＃9] Gitea 安裝與設定：輕量級程式碼託管解決方案 (0則留言, 2022/05/22)
• [Windows] 用Gitea架設自用的Git Server (2則留言, 2017/07/21)
• 啟用Gitea Server的SSH服務，可大幅增加連線速度 (0則留言, 2018/02/15)
• Gitea網頁添加自訂選項以開啟說明文件 (0則留言, 2022/09/01)
• 撰寫git info工具以模擬svn info功能 (0則留言, 2014/09/01)
• 建立測試環境以git rebase -i變更Commit歷史 (0則留言, 2014/10/08)
• 使用SmartGit整合Subversion中央版本庫與Git本地端操作 (0則留言, 2017/05/05)
• 幫Gitea網站使用Let’s Encrypt SSL憑證的設定步驟 (0則留言, 2022/09/01)
• Git https/SSL 連線失敗時的解決方法 (0則留言, 2022/09/06)
• AutoHotkey與Google+ Commander合用－以滑鼠移動訊息位置 (0則留言, 2011/10/31)
• [Git#1] SmartGit的安裝與設定 (0則留言, 2019/12/29)
• Subversion版本庫匯入Git的步驟與SVN整合步驟 (0則留言, 2014/10/03)