一旦涉及版本控制系統(tǒng)，Git實(shí)際上代表敏捷開發(fā)的水平。Git作為一款強(qiáng)大的開源系統(tǒng)，有較強(qiáng)的靈活性，可以按需匹配任何開發(fā)團(tuán)隊(duì)的工作流程。而這種分布式相比較集中式來說，自然賦予系統(tǒng)更好的性能特征，且允許開發(fā)人員在本地自由實(shí)驗(yàn)，在他們修改到自己認(rèn)為沒有問題時(shí)再發(fā)布到團(tuán)隊(duì)。

[[284893]]

除了靈活性和分布式等優(yōu)點(diǎn)外，Git的主要職能是支持和強(qiáng)化敏捷開發(fā)。將Git視為敏捷開發(fā)的一部分，與單片發(fā)布和集中版本控制系統(tǒng)相比，所有變更可以更快部署。

專家提示： Git是分布式版本控制系統(tǒng)(DVCS)。與CVS或Subversion (SVN)等工具不同，Git允許開發(fā)人員在團(tuán)隊(duì)資源庫中創(chuàng)建個(gè)人獨(dú)有的分支，并與主代碼庫并行存儲(chǔ)。這些自創(chuàng)副本被稱為fork。fork上的工作完成后，開發(fā)人員可以很輕松地將更改上傳至主代碼庫。

方法一：將開發(fā)任務(wù)視為Git的分支

在產(chǎn)品功能細(xì)化并添加至產(chǎn)品路線圖，開發(fā)團(tuán)隊(duì)做好開工準(zhǔn)備后，Git開始發(fā)揮作用。但在正式開發(fā)之前，團(tuán)隊(duì)需要有一個(gè)敏捷功能開發(fā)速成課：產(chǎn)品、設(shè)計(jì)、質(zhì)保(QA)、研發(fā)要開一個(gè)功能啟動(dòng)會(huì)就具體的功能、項(xiàng)目范圍以及為了確保完成這些功能該被分解成什么樣的任務(wù)等方面達(dá)成共識(shí)。在這些被稱為用戶故事的任務(wù)拆解完成之后，任務(wù)會(huì)分配給各個(gè)開發(fā)人員。

Git也是在這個(gè)時(shí)候參與到我們的敏捷開發(fā)流程中。在Worktile，我們會(huì)為每個(gè)獨(dú)立的任務(wù)創(chuàng)建一個(gè)新的分支，無論是新的功能，BUG修復(fù)還是對(duì)現(xiàn)有代碼的調(diào)整，每次代碼的更改都會(huì)創(chuàng)建新的分支作為開發(fā)分支，等我們把功能完全做完之后，會(huì)提交Pull Request 到develop分支或者其他我們穩(wěn)定的分支中，有管理員或者其他有合并權(quán)限的成員進(jìn)行代碼 Review，之后合并代碼。 分支的應(yīng)用使任務(wù)變得直觀易懂，同時(shí)允許團(tuán)隊(duì)在一個(gè)中央代碼庫內(nèi)輕松協(xié)作。開發(fā)人員一旦創(chuàng)建了分支，就意味著他們實(shí)際上擁有獨(dú)立于中央代碼庫之外的個(gè)人代碼庫。

對(duì)敏捷團(tuán)隊(duì)而言，將功能拆分為用戶故事后創(chuàng)建相應(yīng)的分支，意味著開發(fā)團(tuán)隊(duì)的成員可以單獨(dú)處理各自的任務(wù)，基于相同的代碼庫在不同的倉儲(chǔ)下工作。開發(fā)工作量并未因此增加，因?yàn)殚_發(fā)人員能夠更專注在與主倉儲(chǔ)分開的小塊任務(wù)，這樣也避免因?yàn)榇嬖谶^多依賴關(guān)系而減緩開發(fā)進(jìn)程。

專家提示： 除了設(shè)置任務(wù)分支之外，還可以設(shè)置其他類型的Git分支，且它們之間可以兼容并存。例如，我們可以為單個(gè)版本的發(fā)布設(shè)置不同的分支，這樣可以讓開發(fā)人員為特定版本進(jìn)一步制定穩(wěn)定和強(qiáng)化的工作計(jì)劃，而同時(shí)也不會(huì)影響到其他開發(fā)人員開發(fā)未來的版本。

創(chuàng)建單個(gè)版本發(fā)布的分支之后，需要定期將其融合到主分支任務(wù)中，確保所涉及的功能都能兼容到未來的版本中并發(fā)揮作用。為了最大限度地減少積壓，所創(chuàng)建的單個(gè)版本發(fā)布的分支最好盡可能接近計(jì)劃發(fā)布日期。

方法二：充分利用多分支可單獨(dú)測(cè)試的優(yōu)勢(shì)

分支一旦被認(rèn)為已經(jīng)完成并可以進(jìn)行代碼review后，Git就開始在敏捷開發(fā)流程中扮演另外一個(gè)關(guān)鍵角色：測(cè)試。成功的敏捷團(tuán)隊(duì)會(huì)進(jìn)行代碼review并進(jìn)行自動(dòng)化測(cè)試(持續(xù)集成)。為了更好地完成代碼review和測(cè)試工作，開發(fā)人員可以直接通知團(tuán)隊(duì)其他成員該分支已經(jīng)完成可以review，然后提交Pull Request。簡(jiǎn)單來講，Pull Request就是請(qǐng)求其他開發(fā)人員將你已經(jīng)做好可以進(jìn)行測(cè)試的分支合并到主分支上。

如果工具使用得當(dāng)，持續(xù)集成服務(wù)器就可以在合并之前創(chuàng)建并檢測(cè)你提交的Pull Request。這樣做能確保合并分支不會(huì)出現(xiàn)問題。通常情況下，還能讓我們更輕松地重新定位Bug修復(fù)和沖突，因?yàn)樵诟鞣种еg存在分歧時(shí)，Git能夠區(qū)分各分支與主代碼庫之間的差異。

專家提示： 一個(gè)長(zhǎng)期運(yùn)行且未合并到主分支的分支，可能會(huì)影響團(tuán)隊(duì)的敏捷性和迭代能力。如果存在一個(gè)長(zhǎng)期運(yùn)行的分支，就意味著實(shí)際上存在兩個(gè)不同版本的代碼庫，而這將直接帶來更多的bug修復(fù)工作和沖突。最好的解決方式是設(shè)定短期的分支，可以通過將用戶故事拆分為較小的任務(wù)、更為細(xì)致的sprint規(guī)劃以及盡早合并代碼作為隱性特征(dark features)等這些方式來實(shí)現(xiàn)。

方法三：Git確保敏捷開發(fā)的透明度和質(zhì)量

Git/敏捷故事通常與效率、測(cè)試、自動(dòng)化和整體敏捷性有關(guān)。將分支合并到主分支后，敏捷的工作流程就完成了。同樣，通過提交Pull Request將代碼合并后，意味著在代碼完成的同時(shí)，所有文檔中的工作也已經(jīng)完成，團(tuán)隊(duì)其他成員已經(jīng)停止代碼活動(dòng)，且已經(jīng)可以進(jìn)行發(fā)布。這使得敏捷團(tuán)隊(duì)可以快速而自信地進(jìn)行頻繁的發(fā)布：這也是成功敏捷團(tuán)隊(duì)的一個(gè)標(biāo)志。

專家提示： 定期發(fā)布是敏捷開發(fā)的關(guān)鍵。要讓Git適應(yīng)敏捷工作流程，就要確保主分支一直是健康暢通的。這意味著，如果某個(gè)功能尚未做好，就可以等到下次再發(fā)版。如果團(tuán)隊(duì)想嘗試較短的發(fā)版周期，也是可以的。