Git Flow代码管理模型介绍

---

Git Flow 是构建在Git之上的一个软件开发活动源码管理的模型，是在Git之上构建的一项源码管理最佳实践。

此篇只介绍Git Flow的逻辑结构以及各分支作用, 不涉及Git Flow的具体用法, 具体用法请参考Git Flow 发祥地 和 Git Flow 文档

Git Flow 逻辑图:

屏幕快照 2016-04-25 下午6.11.28.png

下面是Git Flow官网的逻辑结构图:

git-model@2x.png

各分支介绍:

1. 主分支 (长期存在)

• master分支
  1. 存放可随时部署的代码. 当开发告一段落, 产生了一份稳定可以部署的代码时, 就可以更新到master分支上. 同时每次更新, 最要打好相应版本号的tag. 项目成功主要表现为源码, master便是存储稳定代码之处, 因此此分支长期存在.
  2. master分支一把创建仓库是默认就创建好了, 命名一般就叫master
• develop分支
  1. develop分支是保持当前开发最新成果的分支, 一般会在此分支上进行晚间构建(Nightly Build)并执行自动化测试.
  2. develop分支产生于master分支, 并长期存在.
  3. 当一个版本功能开发完毕且通过测试功能稳定时, 就会合并到master分支上, 并打好带有相应版本号的tag
  4. develop分支一般命名就叫develop

2. 辅助分支 (在一段时间内存在)

• feature分支
  1. feature分支从develop分支创建
  2. 主要是为了开发某个功能, 或试验某项功能而创建, 开发完成之后需要合并到develop分支上
  3. 如果试验失败, 此分支也可丢弃, 不用合并到develop分支之上.
  4. 此分支可以不推送到远程仓库而只存在与开发者本地.
  5. feature分支除master,develop, release-*, hotfix-*之外随意命名, 个人以为命名为feature-编号或者feature-功能名称为好.
• release分支

  1. release分支是为发布新的产品版本而设计的。在这个分支上的代码允许做小的缺陷修正、准备发布版本所需的各项说明信息（版本号、发布时间、编译时间等等）。通过在release分支上进行这些工作可以让develop分支空闲出来以接受新的feature分支上的代码提交，进入新的软件开发迭代周期。

  2. release分支从develop分支创建而来

  3. release分支结束后需要合并到develop分支和master分支上.

  4. 一般命名为 release-version-code, 如release-6.0

• hotfix分支

  1. 当生产环境中的软件遇到了异常情况或者发现了严重到必须立即修复的软件缺陷的时候，就需要从master分支上指定的TAG版本派生hotfix分支来组织代码的紧急修复工作。

  2. hotfix分支从master分支创建而来

  3. hotfix分支完成后需要合并到master和develop分支

  4. 一般命名为hotfix-version-code, 如 hotfix-6.0

---

参考: 基于git的源代码管理模型——git flow

更多阅读:
Git Flow 项目地址
Git Flow 文档
Git Community Book 中文版
Git Pro 英文版 v2
Git Pro 中文版 v2