一種新的Git分支管理策略

在使用git管理代碼時，分支管理策略是須要開發之間規範統一的。現有的常見分支管理策略有TBD、Github flow，git flow。對於以上策略，本文再也不贅述，有興趣同窗能夠參考這篇文章。Git 分支管理最佳實踐

TBD暫且不說。Github flow因爲沒有統一的開發分支，只有不一樣的feature分支，當多人開發多個需求時，feature分支和feature在發佈測試服時容易相互覆蓋。而git-flow則由於feature分支都合併到develop分支，當下一個版本需求都合併到develop時一塊兒發佈，若是要臨時單獨上線一個功能可能比較麻煩。適用於版本迭代週期比較長，版本需求比較明確的開發團隊。而對於像我司團隊這種需求週期短，開發內容多變，且多人並行開發多需求的狀況可能就都不太適合。所以，咱們對Github flow進行一些改變，制定並規範了一種更爲靈活的分支管理策略。

如圖總共分爲三種分支。和Github flow同樣，master 分支的做用是提供一個穩定可靠的代碼基礎。任何開發人員都不容許把未測試或未審查的代碼直接提交到 master 分支。而develop分支則用於合併正在開發中的功能進行測試。當有一個新的feature或者發現新的bug時，咱們都從master中切出一個分支，修改完代碼後把分支合併到develop中進行測試。當測試不經過則返回feature或者bug分支進行修改，直到測試經過，把feature分支經過Merge request合併到master分支進行發佈。這樣就避免了Github Flow中不一樣的feature分支發佈互相覆蓋的問題，也避免了git-flow功能不能臨時獨立發佈的問題。

固然，以上分支策略也有問題，好比分支切換比較頻繁。若是能有像git-flow同樣的插件工具會輕鬆不少。

分支管理策略是一個見仁見智的問題，沒有絕對最好的，只有最適合本身團隊的。以上。