一旦涉及到版本控制系統(tǒng)，Git實際上代表敏捷開發(fā)的水平。Git作為一款強(qiáng)大的開源系統(tǒng)，有較強(qiáng)的靈活性，可以按需匹配任何開發(fā)團(tuán)隊的工作流程。而這種分布式相比較集中式來說，可以賦予系統(tǒng)更好的性能特征，且允許開發(fā)人員在本地自由實驗，在他們修改到自己認(rèn)為沒有問題時再發(fā)布到團(tuán)隊。
除了靈活性和分布式等優(yōu)點外，Git的主要職能是支持和強(qiáng)化敏捷開發(fā)。將Git視為敏捷開發(fā)的一部分，與單片發(fā)布和集中版本控制系統(tǒng)相比，所有變更可以更快部署。

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

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

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

在Worktile，我們會為每個獨立的任務(wù)創(chuàng)建一個新的分支，無論是新的功能，BUG修復(fù)還是對現(xiàn)有代碼的調(diào)整，每次代碼的更改都會創(chuàng)建新的分支作為開發(fā)分支，等我們把功能完全做完之后，會提交Pull Request 到develop分支或者其他我們穩(wěn)定的分支中，有管理員或者其他有合并權(quán)限的成員進(jìn)行代碼 Review，之后合并代碼。

分支的應(yīng)用使任務(wù)變得直觀易懂，同時允許團(tuán)隊在一個中央代碼庫內(nèi)輕松協(xié)作。開發(fā)人員一旦創(chuàng)建了分支，就意味著他們實際上擁有獨立于中央代碼庫之外的個人代碼庫。

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

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

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

方法二：充分利用多分支可單獨測試的優(yōu)勢

分支一旦被認(rèn)為已經(jīng)完成并可以進(jìn)行代碼review后，Git就開始在敏捷開發(fā)流程中扮演另外一個關(guān)鍵角色：測試。成功的敏捷團(tuán)隊會進(jìn)行代碼review并進(jìn)行自動化測試（持續(xù)集成）。為了更好地完成代碼review和測試工作，開發(fā)人員可以直接通知團(tuán)隊其他成員該分支已經(jīng)完成可以review，然后提交Pull Request。簡單來講，Pull Request就是請求其他開發(fā)人員將你已經(jīng)做好可以進(jìn)行測試的分支合并到主分支上。
如果工具使用得當(dāng)，持續(xù)集成服務(wù)器就可以在合并之前創(chuàng)建并檢測你提交的Pull Request。這樣做能確保合并分支不會出現(xiàn)問題。通常情況下，還能讓我們更輕松地重新定位Bug修復(fù)和沖突，因為在各分支之間存在分歧時，Git能夠區(qū)分各分支與主代碼庫之間的差異。

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

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

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

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