集中式工作流：很多公司使用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分支从而形成闭环开发