常见分支管理策略

对于代码版本控制，从我们在没有工具时的傻瓜式管理，到后来的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提单合并。