一旦涉及到版本控制系統，Git實際上代表敏捷開發的水平。Git作為一款強大的開源系統，有較強的靈活性，可以按需匹配任何開發團隊的工作流程。而這種分布式相比較集中式來說，可以賦予系統更好的性能特征，且允許開發人員在本地自由實驗，在他們修改到自己認為沒有問題時再發布到團隊。
除了靈活性和分布式等優點外，Git的主要職能是支持和強化敏捷開發。將Git視為敏捷開發的一部分，與單片發布和集中版本控制系統相比，所有變更可以更快部署。
專家提示：
Git是分布式版本控制系統（DVCS）。與CVS或Subversion (SVN)等工具不同，Git允許開發人員在團隊資源庫中創建個人獨有的分支，並與主代碼庫並行存儲。這些自創副本被稱為fork。fork上的工作完成后，開發人員可以很輕松地將更改上傳至主代碼庫。
方法一：將開發任務視為Git的分支
在產品功能細化並添加至產品路線圖，開發團隊做好開工准備后，Git開始發揮作用。但在正式開發之前，團隊需要有一個敏捷功能開發速成課：產品、設計、質保（QA）、研發要開一個功能啟動會就具體的功能、項目范圍以及為了確保完成這些功能該被分解成什么樣的任務等方面達成共識。在這些被稱為用戶故事的任務拆解完成之后，任務會分配給各個開發人員。Git也是在這個時候參與到我們的敏捷開發流程中。
在Worktile，我們會為每個獨立的任務創建一個新的分支，無論是新的功能，BUG修復還是對現有代碼的調整，每次代碼的更改都會創建新的分支作為開發分支，等我們把功能完全做完之后，會提交Pull Request 到develop分支或者其他我們穩定的分支中，有管理員或者其他有合並權限的成員進行代碼 Review，之后合並代碼。
分支的應用使任務變得直觀易懂，同時允許團隊在一個中央代碼庫內輕松協作。開發人員一旦創建了分支，就意味着他們實際上擁有獨立於中央代碼庫之外的個人代碼庫。
對敏捷團隊而言，將功能拆分為用戶故事后創建相應的分支，意味着開發團隊的成員可以單獨處理各自的任務，基於相同的代碼庫在不同的倉儲下工作。開發工作量並未因此增加，因為開發人員能夠更專注在與主倉儲分開的小塊任務，這樣也避免因為存在過多依賴關系而減緩開發進程。
專家提示：
除了設置任務分支之外，還可以設置其他類型的Git分支，且它們之間可以兼容並存。例如，我們可以為單個版本的發布設置不同的分支，這樣可以讓開發人員為特定版本進一步制定穩定和強化的工作計划，而同時也不會影響到其他開發人員開發未來的版本。
創建單個版本發布的分支之后，需要定期將其融合到主分支任務中，確保所涉及的功能都能兼容到未來的版本中並發揮作用。為了最大限度地減少積壓，所創建的單個版本發布的分支最好盡可能接近計划發布日期。
方法二：充分利用多分支可單獨測試的優勢
分支一旦被認為已經完成並可以進行代碼review后，Git就開始在敏捷開發流程中扮演另外一個關鍵角色：測試。成功的敏捷團隊會進行代碼review並進行自動化測試（持續集成）。為了更好地完成代碼review和測試工作，開發人員可以直接通知團隊其他成員該分支已經完成可以review，然后提交Pull Request。簡單來講，Pull Request就是請求其他開發人員將你已經做好可以進行測試的分支合並到主分支上。
如果工具使用得當，持續集成服務器就可以在合並之前創建並檢測你提交的Pull Request。這樣做能確保合並分支不會出現問題。通常情況下，還能讓我們更輕松地重新定位Bug修復和沖突，因為在各分支之間存在分歧時，Git能夠區分各分支與主代碼庫之間的差異。
專家提示：
一個長期運行且未合並到主分支的分支，可能會影響團隊的敏捷性和迭代能力。如果存在一個長期運行的分支，就意味着實際上存在兩個不同版本的代碼庫，而這將直接帶來更多的bug修復工作和沖突。最好的解決方式是設定短期的分支，可以通過將用戶故事拆分為較小的任務、更為細致的sprint規划以及盡早合並代碼作為隱性特征（dark features）等這些方式來實現。
方法三：Git確保敏捷開發的透明度和質量
Git/敏捷故事通常與效率、測試、自動化和整體敏捷性有關。將分支合並到主分支后，敏捷的工作流程就完成了。同樣，通過提交Pull Request將代碼合並后，意味着在代碼完成的同時，所有文檔中的工作也已經完成，團隊其他成員已經停止代碼活動，且已經可以進行發布。這使得敏捷團隊可以快速而自信地進行頻繁的發布：這也是成功敏捷團隊的一個標志。
專家提示：
定期發布是敏捷開發的關鍵。要讓Git適應敏捷工作流程，就要確保主分支一直是健康暢通的。這意味着，如果某個功能尚未做好，就可以等到下次再發版。如果團隊想嘗試較短的發版周期，也是可以的。