一旦涉及到版本控制系統，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適應敏捷工作流程，就要確保主分支一直是健康暢通的。這意味著，如果某個功能尚未做好，就可以等到下次再發版。如果團隊想嘗試較短的發版週期，也是可以的。

文章來源：Worktile敏捷部落格

歡迎訪問交流更多關於技術及協作的問題。

文章轉載請註明出處。

&n