團隊開發Git分支管理策略

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

下面的內容確定不是什麼教你如何用git提交代碼，合併分支之類的。如今本人要從寫術的層面提高一下本身文章的品質到道的層面。

使用git帶來的分支疑惑

git 爲何好，爲何要用 git，這不是我本文想要說明的問題。

這裏想要給你們分享一下本身使用過程當中產生的疑惑，以及解決的這些疑惑的過程。話又說回來，我如今依然充滿疑惑。真不知道30歲的時候會不會不惑。

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

圖片來源：阮一峯老師博客

個人疑惑：

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

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

3. 若是線上產生了bug該經過什麼樣方式的分支去修復？

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

用成熟的工做流來解決問題

在解答上面的疑惑前，先介紹幾個工做流，而後經過工做流的模式，來進行解答。由於咱們必須在某種設定的情景下，才能討論解決問題的思路。

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

• Git flow

• Github flow

• Gitlab flow

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

我如今採用的是 Git flow ，通過本身的實踐，確實好用，解決很多問題。而後若是發現與本身的實際狀況有些出入，能夠根據需求作出些變更調整。

個人選擇

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

• 主分支master

• 開發分支develop

而後，存在三種輔助分支，都是短時間的，而且一半狀況下只應該存在本地，不要提交到遠程庫。

• 功能分支（feature branch）

• 補丁分支（hotfix branch）

• 預發分支（release branch）
  在進行上面的分支時，建議的命名規範：feature-xxx、release-xxx、hotfix-xxx

話外：我之前喜歡用下劃線，後來發現打中線不須要按 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必定要結合它的各類鉤子來使用，提高開發效率。這裏後面來介紹下。

參考資料:

• [1]Git 工做流程

• [2]介紹一個成功的 Git 分支模型

介紹

我是何磊，主要工做就是寫代碼，持續創業者（之因此持續是由於到如今尚未乾成功過一件事）。若是你有興趣歡迎關注我，我會分享技術，還有生活，固然還有我創業的故事（說出個人痛，讓你開心一下）。