團隊開發Git分支管理策略

開發生涯的前三年都是使用svn，回首放佛如前世。自從用了git，整個人都神經了。

下面的內容肯定不是什麼教你如何用git提交**，合併分支之類的。現在本人要從寫術的層面提公升一下自己文章的品質到道的層面。

git為什麼好，為什麼要用git，這不是我本文想要說明的問題。

這裡想要給大家分享一下自己使用過程中產生的疑惑，以及解決的這些疑惑的過程。話又說回來，我現在依然充滿疑惑。真不知道30歲的時候會不會不惑。

在使用git過程中，它的分支功能讓我真的欣喜若狂，不過這是把雙刃劍，一不小心你會得到這種git路徑圖：

我的疑惑：

1. 那麼團隊中我們該使用怎樣的分支策略來進行開發協作？

2. 在多人的團隊中，我們應該在master分支上直接開發嗎？

3. 如果線上產生了bug該通過什麼樣方式的分支去修復？

4. 當有多個分支的時候，測試如何有效的參與進來每乙個分支的測試？

在解答上面的疑惑前，先介紹幾個工作流，然後通過工作流的模式，來進行解答。因為我們必須在某種設定的情景下，才能討論解決問題的思路。

下面三種工作流方式，都是採用功能驅動開發，也就是先有需求產生，然後誕生對應的分支，然後開發，最後合併回來，完成使命被刪除。

關於這三種工作流的詳細介紹，建議看看這篇文章-阮一峰

我現在採用的是git flow，經過自己的實踐，確實好用，解決不少問題。然後如果發現與自己的實際情況有些出入，可以根據需求做出些變動調整。

我選擇了 git flow，它的主要特點是，長期存在兩個分支：

* 主分支master

* 開發分支develop

然後，存在三種輔助分支，都是短期的，並且一半情況下只應該存在本地，不要提交到遠端庫。

* 功能分支（feature branch）

* 補丁分支（hotfix branch）

* 預發分支（release branch）

在進行上面的分支時，建議的命名規範：feature-***、release-***、hotfix-***

話外：我以前喜歡用下劃線，後來發現打中線不需要按shift，哈哈，從此開始中線時代。

什麼時候要功能分支？當你拿到乙個需求，或者不是乙個立馬需求上線的bug修復，那麼就應該從develop開乙個分支出來，完成這部分工作。完成後合併到develop分支。

什麼時候要預發分支？

這個分支是為預發準備的，測試的介入，也只應該在該分支產生時才介入。當我們不管是新功能開發，還是一般的bug修改都差不多了。就應該從develop產生乙個release分支，交給測試，如果有bug直接在上面修改。全部完成後，合併回develop，並且合併到master。

關於這個分支我得再多說幾句。因為這是非常重要的一步，如果我們使用了 git 鉤子，當合併到master的時候，會自動發布到線上，所以這是臨上線的最後一道屏障。

同時這裡也解決了我乙個疑惑，測試如何參與到git的每個分支中來？答案是：測試不應該參與到每個分支中來，只應該參與到release分支中去。其它的開發分支，都應該由開發人員自己測試，測試沒有問題的時候才准許合併到develop，這就要求每乙個開發要提高自己交付的產品質量，如何確保自己交付的產品質量？自動化測試是個不錯的選擇，好了，打住，這不是咋們今天的主要任務，這個話題改天再聊。

什麼時候需要補丁分支？

這種情況越少越好。因為它產生的原因是：線上出了bug，並且必須馬上修復，不管你身在何方，當手機響起，拿出電腦改bug吧。

它與release很像，都需要完成後，同時合併到:master與develop。不同的是，它需要從master上開乙個分支出來。

注意這裡沒有測試的介入，一半來說都是**上某乙個小的緊急bug，雖然很嚴重，但是可以很容易改動。當然如果有一些例外情況，應該讓測試進行測試後再合併、發布。

git開發很好用，但是要按照一定規則合理使用分支。

另外，除了:master與develop分支，其它分支都不應該出現在遠端倉庫中。

用git一定要結合它的各種鉤子來使用，提公升開發效率。這裡後面來介紹下。

團隊開發Git分支管理策略

Git分支管理策略

Git分支管理策略

Git分支管理策略

相關推薦