如何讓Git適應敏捷開發流程？

一旦涉及版本控制系統，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敏捷博客

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

文章轉載請註明出處。