Git的推廣心得 | Jeff的妙想奇境

Git的推廣心得日期：2010-12-22 作者：jeff這兩周已經開始在公司幾個項目/產品里推廣Git了，有一些心得，在此分享：工具神馬的都是浮雲實際上，工具神馬的都是浮雲！Git或HG之類的DVCS就是神器嗎？不，充其量也只是另一個VCS或SCM，所謂的分散式、輕量級分支神馬的在某些人看來或許是扯蛋的玩意，人家可能用SVN用得不知有多爽多出神入化呢。如果你僅僅是因為要推廣一種新工具而去推廣Git，那你一定會飽吃閉門羮。不信試試。真正重要的，是駕馭在工具上面的靈魂（思想），有些人雖然用著Git，但只把Git當作備份工具用；有些人儘管還用著古老的搶佔式的VSS，但提交的守則卻是規規範范，標籤打得清晰條理！前者不管用什麼版本管理工具，都是YAST（Yet Another ScmToolkit），而後者不管用什麼管理工具，都能把代碼版本管理得齊齊整整。記住一點：不要把版本管理工具當作代碼備份工具用！否則，你需要的只是dropbox。既然工具是浮雲，那我為什麼還選擇Git？嘿，當你的團隊開始有了強有力的版本管理意識支持後，就會下意識地選擇方便趁手的工具（好吧，我這裡不說強大），Git實際就是這麼一種工具，適合各種各樣有潔癖的人、提交狂人等。規範地使用SCM才是正經事如果你的團隊習慣把SCM當備份工具用，那麼恭喜你，你有足夠好的切入點推廣Git了。如何判斷一個團隊是否把SCM當作備份工具了，有大概以下幾個可供參考的現象：一古腦兒的提交文件，有時1個文件，有時十幾個文件，N個功能點一齊提交備註的特徵：「略」，「提交一些代碼」，「fix一個Bug」，「今天的代碼」等從來不給代碼打上版本號，程序從頭到尾只有唯一一個版本，就是Now遇見衝突就慌張，不懂處理等等我推廣Git，目的不是為了Show up，說我懂得一個很潮的東西，你們也跟著用吧，而是要徹底改變團隊把SCM當備份工具用的習慣，是為產品代碼質量負責。代碼版本管理，最終目的是要實現代碼版本的可控性，包括大至版本級的重取，包括功能級別的增減，甚至是小至commit級別的回滾。我用以達到這種可控性的是一些規範，而非Git本身（當然Git及它的擴展Git flow立功不小）。我制定的規範大致有兩個：雙分支代碼結構嚴格的代碼提交規範並有一個推薦的（非強制的）最佳實踐：使用git-flow輕鬆控制提交粒度雙分支代碼結構雙分支指項目推進過程中總是保持使用兩個主分支：開發分支(develop)、成品分支(master)。1）開發分支（develop）日常的開發工作都是圍繞該分支進行。開發分支上的代碼只有在封版的時候才會被合併到master分支。本地的develop分支，開發人員在上面開發功能並提交，當完成一個完整的功能開發並通過測試時，才能把代碼push到遠程的develop分支。遠程的develop分支上的代碼，要求在任何時候總是可以通過編譯，所以每次隊員把代碼push到伺服器上之前，需要確保自己的代碼已通過編譯並測試。遠程的develop分支的代碼會用於項目的自動構建。2）成品分支（master)該分支上面的代碼總是穩定的，成品級的。只有在每次發布新版本的時候，才會從develop上面把上版本開始到現版本的修改移到master分支，master分支通過標籤(tag)來區分不同的代碼版本。產品的實施人員所面對的總是該分支。代碼提交規範代碼提交規範有三大點，必須嚴格遵守：控制好提交粒度。每次的提交都必需具有獨立性的原子性，建議是以一個功能點或Bug fix為單位；無直接關聯的文件不能在同一次提交；除了初次提交，盡量不用commit -a。認真對待提交備註，多花一分鐘回想本次提交的代碼所含的意義，清晰描述下來，很有可能以後看備註的人是你。編譯、運行及測試沒通過的代碼不允許提交到伺服器基本上，嚴格遵守上面的代碼提交規範，在雙主分支的結構上協作，過程馬上會變得舒服，如果加上一個提交粒度輔助工具的配合，那麼效果更佳。善用git-flowgit-flow的介紹可以參考我之前的文章（一、二），在我的實踐中，開發團隊當中使用git-flow的話，使用最多的命令僅是git flow feature star/finishxxx，版本的發布只需要有一個人負責就行，所以git flow release start/finishvxxx這樣的命令他們基本上可以不懂，hotfix那些更遠的點的功能則可以到時再說。所以，在團隊內使用git-flow的難度並不大，最大阻礙可能是不能與現有的Git可視化工具結合。使用git flow feature命令的益處在於：方便地實現功能級別的粒度管理，讓功能級的回滾更簡單。很好地隔離同時開發的功能代碼，你可以同時本地start多個feature，而新代碼互不相干擾目前git-flow在團隊內並不強制使用，不使用git-flow的前提是要使用雙分支代碼結構以及遵守提交規範，和細心地在各分支之間切換。有git-flow那麼方便的工具在，何樂而不用呢？又是階段性小結在多人的團隊內推廣新的思想或新工具不容易，問號多，大家水平參差不齊等因素都會制約著推廣的成效。這一次的推廣，我準備了比較長的時間，包括學習、熟悉Git，反覆思考和對比，最終確信Git推廣好了，對團隊、產品甚至我自己都是大大的益的。我覺得，在向別人推薦一種東西的時候，最好確保你對它非常了解了，包括它的好處，壞處。由於大家水平參差不齊，不要指望一次培訓就可以擺平。儘可能去到隊員的位置上，幫助他們開始。因為你是花了幾個月的時間來實踐的東西，怎麼能要求他們聽你一堂課就學會？最後附上我在公司培訓用的PPT：Git

View morepresentations fromjeffkit.點擊這裡下載：git
推薦閱讀：