对于代码版本控制，从我们在没有工具时的傻瓜式管理，到后来的svn，再到普及git管理。git的分支管理策略，针对于不同规模的团队、不同的项目开发流程演变出多个版本，下面大体做下介绍。
几种版本控制方式
本地管理
- 每一版本对应一个文件夹；通过复制粘贴来操作迭代及版本维护。
中心化管理
- 多了一个中央服务器来管理版本；
- 从中央下载版本，变更后同步到服务器；
- 多人一起操作一个版本。
分布式管理
- 在中央基础上多了本地仓库；
- 本地仓库可以独立处理版本迭代；
- 中央仓库可以实现多人协作。
git和svn对比
- svn中心化管理，git分布式管理；
- svn分支管理没有git灵活；
- svn简单明了上手简单，git需要学习成本；
- svn需要网络支持，git有本地仓库支持对网络依赖不强；
flow
以下是目前主流的分支策略。
git flow
- 最基本的git工作流：5类分支（master、开发分支、特性分支、发布分支、修复分支），2个主分支（master、开发分支）；
- 从master分支切出开发分支、修复分支，这两个分支最终合入master分支；修复分支也会合入当前开发分支；
- 特性分支从开发分支切出；
- 发布分支从开发分支切出；发布分支发布后合并到master分支，打上tag。
- 优点：该有的都有；
- 缺点：复杂、长久分支造成冲突比较多。
github flow
- 极简化的git工作流，2类分支（master、开发分支），1个主分支（master）；
- 从master切出开发分支；
- 依靠github pull request来操作；
- 有评审合并的流程；
- 优点：不用管那么多分支；每个分支合并后都有对应版本号；
- 缺点：针对中小型团队是可以的，稍大点的团队不能满足多分支管理。
trunkbased
- 为解决冲突而生的git工作流，2类分支（master、发布分支），1个主分支（master）；
- 所有人在master分支上开发；
- 分支随时满足发布，需要发布时候创建发布分支，并打上版本号；
- 修复bug在master分支进行；
- 优点：删繁从简，敏捷最适合，解决冲突的基本上没了；
- 缺点：多个环境部署会碰到问题，要保证每一个提交都能正常运行。
aoneflow
- 阿里的git工作流；3类分支（master、特性分支、发布分支），1个主分支（master）；
- 3个原则：a.从master切出特性分支；b.开发分支灵活的创建发布分支；c.上线后删除特性分支和发布分支，打tag;
- 优点：灵活的安排发布分支，支持长时分支；
- 缺点：有长时分支，就会有冲突。
当前实践
- 需求：
- 多环境；多分支；灵活发布；减少冲突；
- 分支
-
master，主干分支，最稳定版本，所有版本切出源头。
-
开发分支，dev1.0.0，跟随迭代版本号，开发环境公同开发版；
-
测试分支，release1.0.0，随时可以发布分支，从dev1.0.0合并，部署测试环境和预发布环境；
-
特性分支，不能跟随版本一起上线的，从master切出，合并到要上线当周的开发分支，要求每周自行合并master；
-
master，由管理者维护，同时管理分支创建；
-
测试分支加保护，依靠pull request，在gitlab/github提单合并。
-
