近期随着团队规模的扩大以及业务需求的逐渐增长，我花时间思考了团队的代码协作方式，过程中有些收获跟大家分享一下。
首先推荐几篇文章：
阮一峰的博客介绍了比较主流的集中Git工作流程，再加上这里提到的SVN时代的单主干模型，大家应该有个比较全面的认识了。
那么这么多的方式应该如何选择呢？我目前的理解是：
单主干模式
主干开发，tag或分支发布。这个应该不用考虑了，小项目，两三个人应该还可以玩玩，否则可能应该可以忽略了。
Git Flow
适用于长周期的，基于版本发布的项目。不太适合频繁迭代的项目。
要点：长期维护master和development两个分支。master保持绝对的纯净，更新只来自development的merge。development的更新来自其他所有功能branch的merge。在频繁迭代的项目中，这两个分支基本重合了，所以意义就不大了。
变更的开发过程：首先从development分支创建feature分支，进行相关开发，然后merge到development。之后这个feature分支就可以被删除了。bugfix和预发布也是同理
稍微繁琐，一般通过脚本来简化操作。
GitHub Flow
分支开发，主干审查合并。流程简单。其问题在于：master上的最新commit不等于正式版本：刚发布的版本很快会被新提交更新。所以经常不得不新建production分支来跟踪线上版本，以应对相关版本的bugfix等等。
GitHub flow 的好处在于非常简单实用。开发人员需要注意的事项非常少，很容易形成习惯。当需要进行任何修改时，总是从 master
分支创建新分支。完成之后通过 pull request 和相关的代码审查来合并回 master 分支。GitHub flow
要求项目有完善的自动化测试、持续集成和部署等相关的基础设施。每个新分支都需要测试和部署，如果这些不能自动化进行，会增加开发人员的工作量，导致无法有效地实施该流程。这种分支实践也要求团队有代码审查的相应流程。
GitLab Flow
上游为先：Upstream First。严格设定分支优先级，只有上游采纳的变更才能流到下游。
针对持续发布的情况：
针对版本发布的情况：
总结
这个总结真的很好。
还有这个网友的回答：
个人最终的补充：
- 个人所在的算法部门其实是整个系统的一个模块，所以我倾向于使用GitHub+GitLab的方式
- 首先，针对相关算法需求，分支开发，主干通过pull request合并。要有全面的测试和code review
- merge到主干的节点必须是测试通过的可立即发布的节点
- 如果发布的版本需要持续跟踪，或者不能做到立即发布（代码ready后到发布上线中间时间较长，如app审核，上线窗口限制，平台方只能拉去分支的最新commit等等），那么需要新建realese分支以进行跟踪。因为等待发布的同时，master仍然在不断更新。