就像代碼需要代碼規范一樣，代碼管理同樣需要一個清晰的流程和規范
Vincent Driessen 同學為了解決這個問題提出了 A Successful Git Branching Model
下面是Git Flow的流程圖，與SVN分支策略相比，Git分支流程復雜了很多，除了要維護兩個長期的分支master和develop外，還有很多臨時性分支如hotfix等，甚至有些用SVN分支思維的同學還有疑問，這種模式分支合並后豈不是增加了很多重復測試的工作量，因為理論上分支測試后，任何代碼的改動合並到其它分支都是要重新回歸測試才可以的。對此要用Git分支思維才能更好理解，Git用這樣的分支策略就是為了應對實際中常出現的多人多版本並行開發的情況更方便有效率，如果實際開發過程中真像SVN開發分支線性向前迭代，則分支合並只是簡單的移動分支指針並不用重新測試（因為它們是同一套代碼）。
Git分支模型是考慮到基於版本分布，如果有些網站要“持續發布”，則沒必要同時維護master和develop分支，為此GitHub和GitLab都做了對應的分支流程改進。
Git flow工作流評價：
- Git flow的優點是清晰可控，缺點是相對復雜，需要同時維護兩個長期分支。大多數工具都將
master當作默認分支，可是開發是在develop分支進行的，這導致經常要切換分支，非常煩人。- 更大問題在於，這個模式是基於"版本發布"的，目標是一段時間以后產出一個新版本。但是，很多網站項目是"持續發布"，代碼一有變動，就部署一次。這時，
master分支和develop分支的差別不大，沒必要維護兩個長期分支。GitHub flow工作流評價：
- Github flow 的最大優點就是簡單，對於"持續發布"的產品，可以說是最合適的流程。
- 問題在於它的假設：
master分支的更新與產品的發布是一致的。也就是說，master分支的最新代碼，默認就是當前的線上代碼。- 可是，有些時候並非如此，代碼合並進入
master分支，並不代表它就能立刻發布。比如，蘋果商店的APP提交審核以后，等一段時間才能上架。這時，如果還有新的代碼提交，master分支就會與剛發布的版本不一致。另一個例子是，有些公司有發布窗口，只有指定時間才能發布，這也會導致線上版本落后於master分支。- 上面這種情況，只有
master一個主分支就不夠用了。通常，你不得不在master分支以外，另外新建一個production分支跟蹤線上版本。Gitlab flow工作流：
- Gitlab flow 是 Git flow 與 Github flow 的綜合。它吸取了兩者的優點，既有適應不同開發環境的彈性，又有單一主分支的簡單和便利。它是 Gitlab.com 推薦的做法。
