Git Flow

---

使用Git Flow的目的是为了更好的进行版本管理和持续集成，有些细节并不一定要遵循这个模型，可以根据团队规模进行简单的调整，适合的才是最好的。

模型解析

主要分支

远端仓库中拥有两个主要分支，具有无限的生命周期：

• master：origin/master 源代码 HEAD 总是反映生产就绪状态的分支
• develop: origin/develop 源代码 HEAD 始终反映了下一版本中最新交付的开发更改的状态

当 develop 分支中的源代码稳定达到发版要求并准备发版时，合并当前版本代码至master， 然后使用版本号进行标记。这时 master 就是一个新的生产版本，当然我们也可以配置 git hook 的脚本自动构建并推送到我们的生产服务器

辅助分支

针对上面的 Git Flow 模型我们在主要分支上扩展了辅助分支，用以辅助解决并行开发团队成员间的配合与快速迭代过程中的 bug 修复以及功能追踪的问题，这些分支都有特定的目的并不是永久存在的，最终会被删除：

• Feature branches：功能分支

• Release branches：发布分支

• Hotfix branches：热修复分支

Feature Branches

由 develop 分支检出，必须合并回 develop，命名约定：

格式：feature- + 功能描述，如果通过 issue 管理 建议加上 issue号前缀

功能分支主要用于为即将发布或将来的版本开发新功能，功能分支只要处于开发阶段，就会一直存在，但最终会合并回 develop 分支（将新功能添加到即将发布的版本中）或者丢弃(需求彻底作废时)。

Release Branches

发布分支为预发布的生产版本，每个发布分支都分配了一个版本号，允许修复小错误并为发布准备元数据 （版本号、构建日期等）

• 创建发布 由 develop 分支检出，必须合并回 develop 和 master，命名约定：

  格式：release- + 版本号 例如：release-1.0.1

• 完成发布

  当 release 分支达到发版标准时，合并至 master 分支，并在 master 打上对应版本的 tag 号标识，最后将发布分支上 所做的更改合并回 develop 分支，以便将来的版本也包含在 release 分支上做的错误修复

Hotfix Branches

热修复分支和发布分支非常像，因为他们都是准备新的生产版本，尽管是计划之外的。源于必须立即采取措施解决生产版本的严重错误

• 创建热修复 由 master 分支检出，必须合并回 develop 和 master，命名约定：

  格式：hotfix- + 版本号 例如：release-1.0.1.1

• 完成热修复

  当热修复完成时，需要合并至 master 分支，并在 master 打上对应版本的 tag 号标识，最后将热修复所做的更改合并回 develop 分支，以便将来的版本也包含在热修复分支上做的错误修复

  特别说明：当发布分支当前存在时，需要将修补程序更改合并到该发布分支中，而不是develop

  在发布分支完成时，根据上面流程合并回 develop 时，就包含了热修复的代码

  如果 develop 立即需要此错误修复并且不能等待发布分支完成，也可以立即以安全地方式将错误修复合并到 develop

  

参考建议

为什么使用Git?

A successful Git branching model