hg flow

Introduction

hg flow 是一种开发模式,采用生产(Production)、发布(Release)、开发(Develop)完全分离的分支模型支撑多人团队的开发模式。hg flow 的开发模型借鉴自 git flow

git flow 的流程图如下:(hg flow 的流程同理,只不过大家习惯的分支名略有不同而已)

git-flow

Installation

其核心是一个 python 文件,以插件的形式加入到 hg 中。

  1. 下载并解压得到hgflow.py,随便放到一个你喜欢的目录下
  2. 编辑$HOME/.hgrc(Windows 下是%USERPROFILE%/Mercurial.ini),添加以下内容:
    1
    2
    3
    4
    5
    6
    [extensions]
    mq =
    flow = /PATH/TO/hgflow.py

    [flow]
    autoshelve = true

Branches

  • Production
    也就是我们经常使用的 Default 分支,这个分支包含最近发布到生产环境的代码,最近发布的 Release, 这个分支只能从其他分支合并,不能在这个分支直接修改
  • Develop
    这个分支是我们是我们的主开发分支,包含所有要发布到下一个 Release 的代码,这个主要合并与其他分支,比如 Feature 分支
  • Feature
    这个分支主要是用来开发一个新的功能,一旦开发完成,我们合并回 Develop 分支进入下一个 Release
  • Release
    当你需要一个发布一个新 Release 的时候,我们基于 Develop 分支创建一个 Release 分支,完成 Release 后,我们合并到 Default 和 Develop 分支
  • Hotfix
    当我们在 Production 发现新的 Bug 时候,我们需要创建一个 Hotfix, 完成 Hotfix 后,我们合并回 Default 和 Develop 分支,所以 Hotfix 的改动会进入下一个 Release

Commands

初始化工作区

1
2
cd <my_repository_dir>
$ hg flow init

会提示你

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
flow: Global configuration:
flow: autoshelve: on

flow: warning: You have the following open branches. Will initialize flow for all of them.
flow: warning: default
flow: warning: develop (active)

Branch name for master stream: [default]
Branch name for develop stream: [develop]
Branch name for feature stream: [feature/]
Branch name for release stream: [release/]
Branch name for hotfix stream: [hotfix/]
Branch name for support stream: [support/]
2 files updated, 0 files merged, 1 files removed, 0 files unresolved
2 files updated, 0 files merged, 0 files removed, 0 files unresolved

一路回车保持默认就行了

功能开发/BUG 修复

在开发阶段,让每个人、小组进行功能开发或者是Bug修复。目的是大家相互不干扰。

开始一个功能/Bug修复

1
hg flow feature start <name>

这个命令会基于开发分支(develop)新建一个功能开发分支 feature/<name>,并自动切换到此分支。

完成一个功能/Bug修复

1
hg flow feature finish <name>

这个命令会 关闭 功能开发分支feature/<name>,并把内容合并到开发分支。

在功能开发分支中切换

1
hg flow feature change <name>

这个命令会在不同的功能开发分支中进行切换,切换到 feature/<name> 分支中。

关闭功能开发分支(未完成)

1
hg flow feature close <name>

放弃这次功能开发,关闭分支 feature/<name>

准备发布新版本

当功能开发完成,全面进入测试阶段时候,则采用发布分支。发布分支的目的是使得测试阶段的代码和其他与本次发布无关的功能性代码隔离开,相互不干扰。

开始准备发布

1
hg flow release start <name>

这个命令会基于开发分支(develop)新建一个发布分支 release/<name>,并自动切换到此分支。

当有这个分支的时候,开发阶段应该进入全面测试期,这个分支上只负责修改测试出现的bug等问题。理论上此时不再进行新功能开发,也就是需求冻结阶段。

完成一个发布

1
hg flow release finish <name> [tag_name]

这个命令会 关闭 发布分支release/<name>,然后执行如下操作:

  • 合并到生产分支 (default)
    • 如果指定 tag_name,则合并标记 tag_name 到生产分支
    • 如果未指定 tag_name,则合并分支 release/<name> 到生产分支
  • 打这次发布的tag <version_tag_prefix><name> 如 v1.0
  • 合并 release/<name> 到开发分支 (develop)

关闭待发布分支(未完成)

1
hg flow release close <name>

放弃这次功能开发,关闭分支 release/<name>

热修补

当生产环境出现了一些急于修补的问题,则是用热修补分支。热修补分支是以生产环境的代码作为基础,进行小规模的快速的修补。

开始准备发布

1
hg flow hotfix start <name>

这个命令会基于生产分支(develop)新建一个热修补分支 hotfix/<name>,并自动切换到此分支。

当生产环境出现了一些急需修补的问题,或者一些需求的增加,则可以使用热修补分支进行快速的小型迭代。

完成一个热修补

1
hg flow hotfix finish <name> [tag_name]

这个命令会 关闭 热修补分支 hotfix/<name>,然后执行如下操作:

  • 合并到生产分支 (default)
    • 如果指定 tag_name,则合并标记 tag_name 到生产分支
    • 如果未指定 tag_name,则合并分支 hotfix/<name> 到生产分支
  • 打这次发布的tag <version_tag_prefix><name> 如 v1.1
  • 合并 hotfix/<name> 到开发分支 (develop)

关闭热修补分支(未完成)

1
hg flow hotfix close <name>

放弃这次热修补,关闭热修补分支 hotfix/<name>