Git Flow

GitFlow 工作流

1. GitFlow是什么？

   • GitFlow是一套基于git的工作流程，这个工作流程围绕着项目发布定义了一个严格的如何建立分支的模型。
   • GitFlow规定了如何建立、合并分支，如何发布，如何维护历史版本等工作流程。简单说就是每一个功能特性的开发是在分支上开发，而不是在主干开发，分支开发完毕后再合并到主干上。

2. GitFlow的优势

   • 还处于半成品状态的feature不会影响到主干
   • 各个开发人员之间做自己的分支，互不干扰
   • 主干永远处于可编译、可运行的状态

3. GitFlow分支简述

• 主干分支（master和develop）
  • master分支存储了发布版本的历史，各个版本通tag来标记（git tag -a v0.1）
  • develop分支是一个集成分支，用来整合各个功能feature分支，也方便给master分支上的所有提交分配一个版本号。
• 功能分支（feature）
  • 开发每个新功能都必须新开个feature分支，feature分支派生自develop分支。
  • 开发完成后要合并回develop分支。feature分支永远不会和master分支打交道。
• 待发布分支(release)
  • release分支不是一个放正式发布产品的分支，可以理解为预发布或者待发布分支。
  • 当开发的功能完成并满足发布的条件时，将这些满足条件的feature分支合并到develop分支上，然后从develop分支开出一个release分支，开始准备一个发布版本。
  • 在release分支上，不能再添加新的功能，但是我们可以:
    • 将分支打包给测试人员测试
    • 在这个分支上修改bug
    • 编写发布文档
    • 当到发布日时，发布相关的工作都完成后，release分支合并回master分支，并打出版本标签，发布完成后，release分支合还要并回develop分支。
• 维护分支(hotfix)
  • 维护分支也就是bug修复分支，用来快速修复生产环境的紧急问题。
  • 项目发布后或多或少会有一些bug存在，而bug的修复工作并不适合在develop上做，这是因为:
    • develop分支上可能包含还未验证过的feature
    • 用户未必需要develop上的feature
    • develop还不能马上发布，而客户急需这个bug的修复。
  • 这个分支是唯一一个开放过程中直接从master分支派生来的分支。
    快速的修复问题后，hotfix分支应该被合并回master分支，同时也要合并回develop分支，这样develop分支也能享受到bug修复的好处。然后master分支需要打一个版本标签，例如v0.11。

4.GitFlow的命名约定

分支	命名
主分支	master
主开发分支	develop
标签（tag）	v##，如：v1.0.0
新功能开发分支	feature-games或feature/gamesp
发布分支名	release-1.0.0或release/1.0.0
维护分支	hotfix-update或hotfix/update

参考文档