一旦涉及版本控制系統，Git實際上代表敏捷開發的水平。Git作爲一款強大的開源系統，有較強的靈活性，可以按需匹配任何開發團隊的工作流程。而這種分佈式相比較集中式來說，自然賦予系統更好的性能特徵，且允許開發人員在本地自由實驗，在他們修改到自己認爲沒有問題時再發布到團隊。

除了靈活性和分佈式等優點外，Git的主要職能是支持和強化敏捷開發。將Git視爲敏捷開發的一部分，與單片發佈和集中版本控制系統相比，所有變更可以更快部署。

專家提示：

方法一：將開發任務視爲Git的分支

在產品功能細化並添加至產品路線圖，開發團隊做好開工準備後，Git開始發揮作用。但在正式開發之前，團隊需要有一個敏捷功能開發速成課：產品、設計、質保（QA）、研發要開一個功能啓動會就具體的功能、項目範圍以及爲了確保完成這些功能該被分解成什麼樣的任務等方面達成共識。在這些被稱爲用戶故事的任務拆解完成之後，任務會分配給各個開發人員。

Git也是在這個時候參與到我們的敏捷開發流程中。在Worktile，我們會爲每個獨立的任務創建一個新的分支，無論是新的功能，BUG修復還是對現有代碼的調整，每次代碼的更改都會創建新的分支作爲開發分支，等我們把功能完全做完之後，會提交Pull Request 到develop分支或者其他我們穩定的分支中，有管理員或者其他有合併權限的成員進行代碼 Review，之後合併代碼。

分支的應用使任務變得直觀易懂，同時允許團隊在一箇中央代碼庫內輕鬆協作。開發人員一旦創建了分支，就意味着他們實際上擁有獨立於中央代碼庫之外的個人代碼庫。

對敏捷團隊而言，將功能拆分爲用戶故事後創建相應的分支，意味着開發團隊的成員可以單獨處理各自的任務，基於相同的代碼庫在不同的倉儲下工作。開發工作量並未因此增加，因爲開發人員能夠更專注在與主倉儲分開的小塊任務，這樣也避免因爲存在過多依賴關係而減緩開發進程。

專家提示：

創建單個版本發佈的分支之後，需要定期將其融合到主分支任務中，確保所涉及的功能都能兼容到未來的版本中併發揮作用。爲了最大限度地減少積壓，所創建的單個版本發佈的分支最好儘可能接近計劃發佈日期。

方法二：充分利用多分支可單獨測試的優勢

分支一旦被認爲已經完成並可以進行代碼review後，Git就開始在敏捷開發流程中扮演另外一個關鍵角色：測試。成功的敏捷團隊會進行代碼review並進行自動化測試（持續集成）。爲了更好地完成代碼review和測試工作，開發人員可以直接通知團隊其他成員該分支已經完成可以review，然後提交Pull Request。簡單來講，Pull Request就是請求其他開發人員將你已經做好可以進行測試的分支合併到主分支上。

如果工具使用得當，持續集成服務器就可以在合併之前創建並檢測你提交的Pull Request。這樣做能確保合併分支不會出現問題。通常情況下，還能讓我們更輕鬆地重新定位Bug修復和衝突，因爲在各分支之間存在分歧時，Git能夠區分各分支與主代碼庫之間的差異。

專家提示：

方法三：Git確保敏捷開發的透明度和質量

Git/敏捷故事通常與效率、測試、自動化和整體敏捷性有關。將分支合併到主分支後，敏捷的工作流程就完成了。同樣，通過提交Pull Request將代碼合併後，意味着在代碼完成的同時，所有文檔中的工作也已經完成，團隊其他成員已經停止代碼活動，且已經可以進行發佈。這使得敏捷團隊可以快速而自信地進行頻繁的發佈：這也是成功敏捷團隊的一個標誌。

專家提示：

文章來源： Worktile敏捷博客

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

文章轉載請註明出處。

相關文章