就像程式碼需要程式碼規範一樣，程式碼管理同樣需要一個清晰的流程和規範

Vincent Driessen 同學為了解決這個問題提出了 A Successful Git Branching Model

下面是Git Flow的流程圖，與SVN分支策略相比，Git分支流程複雜了很多，除了要維護兩個長期的分支master和develop外，還有很多臨時性分支如hotfix等，甚至有些用SVN分支思維的同學還有疑問，這種模式分支合併後豈不是增加了很多重複測試的工作量，因為理論上分支測試後，任何程式碼的改動合併到其它分支都是要重新迴歸測試才可以的。對此要用Git分支思維才能更好理解，Git用這樣的分支策略就是為了應對實際中常出現的多人多版本並行開發的情況更方便有效率，如果實際開發過程中真像SVN開發分支線性向前迭代，則分支合併只是簡單的移動分支指標並不用重新測試（因為它們是同一套程式碼）。

Git分支模型是考慮到基於版本分佈，如果有些網站要“持續釋出”，則沒必要同時維護master和develop分支，為此GitHub和GitLab都做了對應的分支流程改進。

Git 工作流程 - 阮一峰的網路日誌

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 推薦的做法。