背景
- 由于 git 项目到后期可能会有太多分支（小伙伴忘记删除），且小伙伴不知道哪个分支是有用的
- 线上紧急 bug 修复不应直接修改 master 代码
git branch 功能很强大，但是没有一套模型告诉我们应该怎样在开发的时候善用这些分支。而 Git Flow 模型就是要告诉我们怎么更好地使用 Git 分支。Git Flow 模型也有相关的插件，可放心食用。
产品迭代周期
可以明确的是，产品开发迭代必须是有一个周期的。这个周期时间，可以由 pm（项目或者产品）指定，不论多短或多长，都应视为一个周期。此概念可帮助该 git-flow 模型执行。
- 周期时间确立之初，需要把周期结束完结的所有 feature 和 bugfix 确定好（feature 和 bug 都视为一个周期内之需求）
- 该周期一旦开始，便不能随便插队新功能 feature。新功能应当放入需求池，延续到下一次迭代周期（该项需要和每个 pm 确认，让其知悉）
- 周期完成后，master 需要打 tag 并发布线上（方便回滚上一个稳定版本），并记录 release note，可追溯
- 产品版本，如果没有的请开始 push 大家用起来吧
分支说明
Master 以及 Develop 这两个分支是长期分支，他们会一直存活在整个 Git Flow 里，而其它的分支大多会因任务结束(执行 finish 命令)而被自动删除，这样无需担心有冗余分支。
Release 是需要打版本号的分支。例如 1.1.2（待定）。
除上述三种分支，其他分支命名规范统一以：功能分支-年/月/日：feature/180827。
倘若有 jira 链接，假设是 radar（该项目）109，可以附上：feature/180827-radar109
Master 分支
- 该分支永远是线上稳定可信赖版本
- 产品经理说线上有问题的时候只能从这个分支切出来 hotfix 分支做热修复
- 可以在该分支打 Tag
- 任何人不允许在该分支直接修改并提交代码
- 只能从别的分支合并到 master
Develop 分支
- 是所有 feature 的基础分支
- 产品经理说开发新功能的时候，基于该分支开始切出新的 feature 分支，而最后所有 feature 分支功能完成后，也会合并回 develop 分支
Release 分支
- 上线前的分支
- rc1，rc2→master
- 不允许在该分支上开发新功能
- 通过询问产品经理，可得知一个周期内的 develop（集齐许多 feature），准备上线了，可以进行 release 发布
- 若产品经理需要临时上线新功能可以拒绝
- 可以进行一些 bugfix
- 为什么不用 develop 作为 release 分支
- 在发布周期内，还可以在 develop 开发新功能
- 一个团队可以忙于发布，另一个团队可以忙于开发下一个周期的新功能
- 需要写 release note
- 在相关 wiki 上记录版本发布内容
Hotfix 分支
- 线上出现故障的时候，紧急修复的分支
- 产品经理说线上某个问题必须修一下，那么从 Master 分支开一个 Hotfix 分支出來进行修复，Hotfix 分支修复完成之后，会合并回 Master 分支，也同时会合并一份到 Develop 分支。
Bugfix 分支
- 线上出现故障的时候，但是并不需要立刻修复
- 新功能开发完毕，合到 develop 分支之后发现有 bug
Feature 分支
- 功能分支
- 从 develop 来，最终完成后会合并回 develop