未完.....修正中
看到国内 大多数项目 默认都是 dev 为主分支，分支众多，颇为混乱。颇为诧异。遂总结出本篇文章，持续修正。 TrunkBased 模型是持续集成思想所崇尚的工作方式，它由单个master分支和许多release分支组成，每个release分支在特定版本的提交点上从master分支创建出来，用来进行上线部署和 Hotfix。在 TrunkBased 模式中，没有显性的feature分支。
GitFlow 模型是若干模式的集大成者，包含一个master分支、一个develop分支、许多的feature分支、许多的release分支和 Hotfix 分支，以及许多繁琐的合并规则。
git flow
gitflow 是最早第一个提出的 git 工作流。虽然完备，但对于现在敏捷 持续集成分支构建。过于复杂。
适用于内部开发大中型项目。不适合微服务项目
【保留分支】
master 针对 master 的每次提交，都要迭代更新 tag 即里程碑。
develop 用于开发，中小项目 可直接在 develop 分支开发。不用 check 出 feature分支。
【可选分支】
feature 用于同时开发多个 不同 功能。新建的功能分支 必须是描述性的名字，以便于别的开发人员查找和理解。
release 用于发布测试，名字基本上是release-tag号。
该分支相对稳定 不再接受新需求。发布即代表版本号定成功，
发布成功后合并到 master 和 视情况合并到 develop。
这里不建议 release-加时间。一定要明确版本号。
如业务需求改动，舍弃这次版本，不对 master 提交。
hotfix 用于修复紧急bug
patch 用于修复功能缺陷
【基本流程】
master -> develop -> master
master -> develop -> featrue -> develop -> master
【标准流程】
master -> develop -> featrue -> develop -> release -> master
【bug流程】
master -> hotfix -> develop
↓
master
【优点】流程清晰可控。
【缺点】流程复杂，效率低。
github flow
github 开发是基于 pr （pull request）的自动化工作流。 这是因为开源项目， 大多参与人员，是没有权限直接提交更新代码。 需要 fork 到自己项目。修改后 提交 pr 到 原来的项目里。由原项目管理员审核 review代码 测试 merge 到 主分支。
简单理解就是 复制一份代码 到自己的项目里。然后你可以随便更新更改自己项目。改完 提交 pr 到原项目。避免所有人瞎改乱造。
不同公司方式可能不同，但都是通过 pr 形式。
【保留分支】
master
主要的开发分支。
因为大多数 git server 都是 master 为主分支。所以以master 为主开发分支。便于理解和开发。
【可选分支】
develop
feature
release
hotfix
patch
【基本流程 && bug流程】
master -> fork代码 -> feature -> pr -> review代码 -> master
【基于issue的开发 && bug流程】
认领issue-> master -> fork代码 -> 新建hotfix分支，修改issue对应 -> pr 指定 issue -> review代码 -> master
【优点】安全可控。开源友好。
【缺点】流程复杂，非活跃项目效率低。
gitlab flow
其实大多公司都是自建 gitlab。
【保留分支】
master
master 默认是主要的开发分支，是最新的。
【可选分支】
develop
feature
release
hotfix
patch
【基本方式】
feature -> mr -> master -> production
【多环境】
feature -> mr -> master -> pre-production -> production
【版本发布】
feature -> mr -> master -> stable
production 方式适合程序集成发布项目。 stable 方式适合对版本迭代要求严格的项目。
对比 github flow 可以看出 加了 production 用来解决 github 对 master 时间不可控的问题。
【优点】清晰可控。开源友好。
【缺点】对比 github flow 增加了需要维护的分支。
TrunkBased
主干开发是助力实现 持续集成 和 持续交付 的关键因素。开发团队的成员一天多次地将代码提交到主干分支
TrunkBased 和 github flow 是类似的
【保留分支】
master || trunk
master 为主要测试开发分支
【可选分支】
develop
feature
release
hotfix
patch
【基本流程】
feature -> master -> release
【master 未更新 bug 流程】
fixbug -> master -> release
【master 已更新 bug 流程】
不要直接在release 改。避免merge 操作麻烦。
release分支tag -> master fixbug -> master cherry pick 到 release -> 更新tag
【feautre 未开发完 release】
使用 Feature Toggle
【优点】持续集成，简单。
【缺点】只有一个主分支，并行开发麻烦。 比较适合快速迭代的微服务项目。
Aone flow
阿里的AoneFlow，它基本上兼顾了 TrunkBased 的“易于持续集成”和 GitFlow 的“易于管理需求”特点，同时规避掉 GitFlow 的那些繁文缛节。
【保留分支】
master
【可选分支】
develop
feature
release
hotfix
patch
【基本流程】
master -> feature -> relase -> master
【bug修复流程】
release || tag -> fixbug -> master
参考地址 总结：
从中我们可以看出，gitflow 不适用敏捷为主的项目。
gitflow 下，持续集成部署的项目，我们的 feautre 分支 需要频繁和并到 develop 。而我们并不能为 多个 feature 准备多个环境。 同时大量的 merge 耗费人力精力。
