前言

特別宣告：本文專為圖靈社群活動“喚醒你心中的佈道師”而寫，歡迎大家積極參與！

特別感謝：本文的風格照搬高翌翔的“佈道體” 從自定義ORM框架到NHibernate——我的識道、行道、佈道之旅

程式設計師雜誌第十二期中講到了企業開發的困境，其中有一點就是企業的流程和工具很難適應新的敏捷開發模式。我認為其中之一就是版本控制系統，本文就是探討一下我是如何來推動這個改變的，也就是我的佈道之旅。

【免責宣告】這裡不是探討兩種技術的好壞，而是如何推動變革，每個技術都有適應的場所，請勿生搬硬套。關於版本控制的選擇，可以看看Martin Fowler寫的版本控制工具(english)

介紹

在傳統企業中，版本控制系統大都採用ClearCase，因為在早期它應該提供了強大的企業應用的功能，我們企業也很早使用了。而且長久以來，在它周圍建立了無數的應用和流程，同事們都覺得它是必須的了。

然而隨著敏捷和開放的推動下，在有些產品用Clearcase開發碰到了很多侷限，比如在家上班，遠端團隊開發。有人開始想到引入其他工具（svn，git）來解決，不過在大型企業中要改變這種基礎的工具是很難的。

我做為一個軟體開發的探索者，努力的想改變點什麼，但不知從何而起。

瞭解分散式版本控制（DVCS）——初識道

開始考慮這個的時候是在2009年初，svn是第一個考慮的物件，因為它在開源中用的最多，sourceforge和eclipse的很多專案多用它，但我總覺得缺了點什麼。

恰好我有個Geek朋友：陳忠克極力推薦一個分散式版本控制工具：mercurial，說實話聽了介紹不是很懂，沒有眼前一亮的感覺。聊了一下，感覺和svn的分支沒有多大區別，還兩層提交呢。

同時他也告訴我還有其他的分散式版本控制工具git，bazaar可供選擇。

不管怎麼樣，我瞭解了這塊領域有了最新的技術，或許能解決我們的問題。

嘗試在日常中使用分散式版本控制——初行道

為了儘快瞭解DVCS，我決定要在日常的開發中用用它，實踐它，儘快的掌握它的關鍵。

由於Geek對mercurial很熟，我就踏踏實實的用mercurial用了兩個星期，不懂就問他，順便查查資料去比較一番。

wooh,wooh，DVCS真是很神奇，很好用，特別對我（作為碼農）的胃口，感覺DVCS天生是為軟體開發用的。

在同一時刻，我又比較深入的看了看其他的系統如git，發現git的生態圈更好一點。在軟體開發中，生態圈會決定將來這個工具的發展趨勢。

• 如eclipse外掛開發郵件中開始討論並決定用git替代svn。
• git有很多的書可供選擇（如 ProGit），git線上網站的內容也極其豐富。
• github也漂亮得提供git的支援。補充一下，那時候bitbucket和github還在同一個水平線上。google code也還不支援git，只有mercurial和svn。

通過這些實踐和了解，發現DVCS：git很適合我們所在的企業產品軟體開發。

宣揚和推廣分散式版本控制——初佈道

要在企業中換一個版本控制工具難度非常大，所以必須要造勢，也就是此處的佈道，我採用了下面的方法：

1. 每月我們都有固定學習新東西的時間，我就推薦了mercurial、git兩個課程，讓大家共同來學習，瞭解它。順便我要看看開發者對它的接受程度，有趣的是，水平越牛的人越是喜歡它，紛紛過來問什麼時候能在產品開發中用上git。
2. 除了開發者，管理者和其他的使用者（配置管理的同事）的想法也很重要。我經常抓住機會和這些人聊DVCS ，聊git，給他們介紹，看看他們有什麼想法。當然他們會不同意我的觀點（有強勢的，有委婉的），我就試圖去說服他們，挖掘出推動這個變化的關鍵因素。

慢慢的我就開始得到了很多如何推動這個變化的材料，以及說服他們的模板（哈哈對症下藥）。

詳細研究版本遷移——再識道

開發者想使用分散式版本控制的呼聲越來越高，管理者也開始認真考慮了。

在企業中，改變所需要的研究評測報告（word，ppt)是必不可少的了，這也給了我一次重新認識集中式和分散式版本控制的過程，我花了更多的時間去想這個改變對企業帶來的好處。實際上開發者有時候不會考慮到整個軟體開發的所有方面，如安全，持續整合等等。報告的大致框架是：

• 現在問題是什麼？
• 什麼是DVCS，git是什麼？
• 能改變什麼？帶來的好處？
• 如果變化，計劃是什麼？

研究報告就不細講了，太技術了，而且有點商業機密，哈哈。

這一期間，使我更詳細的瞭解了git和對企業可能的影響（有好的，有壞的），並制定了相應的對策。

開始在小範圍實施——再行道

佈道需要耐心和機遇，機緣巧合，遷移到git的建議比較順利的被管理層接受了。（我的報告難得那麼順利通過的）。

然後就是要去認認真真的實施了，這不是一個小問題，既然是軟體開發，來不得半點的馬虎，細節決定一切。而且實施的好壞還涉及到自己的面子問題，講笑了。

企業中一般從小範圍開始實施，成功了才推廣，下面是我們的一些實踐。

• 我們用gitolite作為git伺服器，架好試驗平臺，在一個小專案中開始嘗試。
• 人手一本git的書，安排git入門培訓，提高駕馭git的能力。
• 不斷收集資料，提高對git的認識。

還好基本上沒有出大的差錯，雖然有蠻多技術難點的，不過最後都解決了。通過小範圍的使用推廣，我們的技術儲備也加強了（特別是配置管理的人），對下一步的全面實施更有信心。

推廣，並引入gerrit做程式碼審查——再佈道

早期我們用的是gitolite來架git伺服器，它很不錯。不過後來發現gerrit更好用，後來就切換過去使用了。這一點很重要，要不斷探索這些新技術，爭取在大規模推廣前，用一個最適合的工具，否者一用上，在企業中就很難改變了。

git開始在更多團隊和更多產品中使用後，我們不斷加強知識的培訓，而且把相關的系統（如持續整合）都遷移到git上去。一切都還不錯，只是git比想象中還複雜一點。

因為gerrit有很強大的程式碼審查（code review）功能，不久以後這個功能也用上去了，程式碼提交的質量一下子上了一個檔次，這是開始推動git變革時沒有想到的。

結束語

（此處引用高翌翔寫的“佈道體”結束語）

子曰：己所不欲，勿施於人。因此，佈道者在佈道前，須識道、行道，而佈道時應謹記“己之所欲，慎施於人”，身教重於言教，務必身體力行、以身示道！

我的識道、行道、佈道之旅沒有終點，希望能結識更多的同路人 ;-)

其他

本文也是我用git記錄在github上的，你可以看到每次的變化。

如果對此文有興趣，幫忙頂一下，別忘了 @larrycaiyu ，希望有機會有人能幫我推薦到QConf 2012中去分享，到時我們可以探討的更多。

順便推薦蔣鑫的《Git權威指南》，國內少有的好書。