集中式工作流：很多公司使用SVN,Git使用并不熟悉,如果遷移至Git之后可以考慮集中式工作流進行開發，代碼庫只有master一個分支,所有開發者只有本地master和遠端master分支，集中式工作流使用起來雖然簡單，但無法充分利用git的優勢

功能分支工作流： 與集中式工作流不同的地方在于除了master分支以外有功能分支(按功能需求創建的功能分支如third-party-login-feature)，日常開發在功能分支,提測集成時提交Merge Requests(在Bitbucket中是Pull Request)，此處開發者可以進行討論審核代碼,同意后可以合并至master分支,未同意或者讓開發者修改后重新提交可以選擇關閉該MR

Gitflow工作流：兩個主干分支master(正式發布的歷史)和develop(功能集成分支)，開發者應基于develop分支創建feature功能分支用于開發,開發完成后提交merge requests請求合并進develop分支,此時若到了發布窗口,基于此時的develop分支創建發布分支release用于測試,預發布,發布以避免影響develop分支的正常集成合并功能分支；release分支不再有新的功能合并進來，一旦創建只用于bug修復并將修復cherry-pick到develop分支;發布完成后，release分支合并進master并分配版本號打tag用于存放發布歷史;Gitflow工作流方式適用于大型項目

Forking工作流：開發者fork官方的repo到自己的賬號空間,對于官方分支只有只讀權限，開發者通過pr提交給官方審核是否合并進代碼庫;開發者通過同步上游官方的repo來使用其他人的代碼,分支策略可參考上述三種工作流,適合開源項目

針對創業公司參與同一個項目的開發者并不多,過于復雜的分支策略并不能帶來便利;可以參考leancloud的分支模式,根據團隊的使用情況進行調整

介紹下我們當前使用的分支策略：

master：主干分支master用于日常開發的基線

userA： 開發者A日常開發所在分支

release-201603091106: master分支集成測試完成后,構建到預發布環境時自動創建release-201603091106用于發布

hotfix-201603091106 基于當前發布之后的release-201603091106分支用于修復bug,在通過提交merge requests方式合并進release-201603091106，并將修復cherry-pick到master分支

日常開發在userA分支操作，然后提交merge requests請求合并至master分支,本地通過git fetch origin master，然后在userA分支git rebase origin/master將master最新commit合并到本地userA分支從而形成閉環開發