在使用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一樣的外掛工具會輕鬆很多。
分支管理策略是一個見仁見智的問題，沒有絕對最好的，只有最適合自己團隊的。以上。