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