GIT版本管理：Git Flow模型

#0 系列目录#

• 版本管理
• SVN版本管理：场景命令实战
• SVN版本管理：两种开发模式
• GIT版本管理：场景命令实战
• GIT版本管理：Git Flow模型

#1 Git Flow介绍# 咱们都知道, 在 git 的分支功能相对 svn 确实方便许多，并且也很是推荐使用分支来作开发. 个人作法是每一个项目都有2个分支, master 和 develop. master 分支是主分支, 保证程序有一个 稳定版本, develop 则是开发用的分支, 几乎全部的功能开发, bug 修复都在这个分支上, 完成后 再合并回 master.

可是状况并非这么简单. 有时当咱们正在开发一个功能, 但程序忽然出现 bug 须要及时去修复的时候, 这时要切回 master 分支, 并基于它建立一个 hotfix 分支. 有时咱们在开发一个功能时, 须要停下来去开发另外一个功能. 并且全部这些问题都出现 的时候, 发布也会成为比较棘手问题.

也就是说, git branch 功能很强大，可是没有一套模型告诉咱们应该怎样在开发的时候善用这些分支。而Git Flow模型就是要告诉咱们怎么更好地使用Git分支。

简单来讲，git-flow 就是在 git branch git tag基础上封装出来的代码分支管理模型，把实际开发模拟成 master develop feature release hotfix support 几种场景，其中 master 对应发布上线，develop 对应开发，其余几个在不一样的状况下出现。经过封装，git-flow 屏蔽了 git branch 等相对来讲比较复杂生硬的命令(git branch 仍是比较复杂的，尤为是在多分支状况下)，简单并且规范的解决了代码分支管理问题。

简单来讲, Git Flow将 branch 分红2个主要分支和3个临时的辅助分支：

主要分支

master: 永远处在即将发布(production-ready)状态；

develop: 最新的开发状态；

辅助分支

feature: 开发新功能的分支, 基于 develop, 完成后 merge 回 develop；

release: 准备要发布版本的分支, 用来修复 bug. 基于 develop, 完成后 merge 回 develop 和 master；

hotfix: 修复 master 上的问题, 等不及 release 版本就必须立刻上线. 基于 master, 完成后 merge 回 master 和 develop；

#2 Git Flow使用#

##2.1 Git Flow安装构建## 安装 git-flow：

➜ brew install git-flow

做者还提供了 git-flow 命令工具，在一个全新目录下构建 git-flow 模型：

➜ git flow init

接着它会问你一系列的问题，蛋定！尽可能使用它的默认值就行了：

No branches exist yet. Base branches must be created now.
Branch name for production releases: [master]
Branch name for "next release" development: [develop]
How to name your supporting branch prefixes?
Feature branches? [feature/]
Release branches? [release/]
Hotfix branches? [hotfix/]
Support branches? [support/]
Version tag prefix? []

或者在现有的版本库构建：

➜ git flow init
Which branch should be used for bringing forth production releases?
   - master
Branch name for production releases: [master]
Branch name for "next release" development: [develop]

How to name your supporting branch prefixes?
Feature branches? [feature/]
Release branches? [release/]
Hotfix branches? [hotfix/]
Support branches? [support/]
Version tag prefix? []

这样一个 git-flow 分支模型就初始化完成。

##2.1 场景1：新功能开发，代号 f1##

1. 基于develop，开启新功能分支开发

完成前面构建操做，当前所在分支就变成 develop. 任何开发都必须从 develop 开始：

➜ git flow feature start f1

git-flow 从 develop 分支建立了一个新的分支 feature/f1，并自动切换到这个分支下面。而后就能够进行 f1 功能开发，中间能够屡次的 commit 操做。

将一个 f1 分支推到远程服务器，与其余开发人员协同开发：

➜ git flow feature publish f1

或者

➜ git push origin feature/f1

2. 完成功能开发，结束新功能分支并删除：

➜ git flow feature finish f1

feature/f1 分支的代码会被合并到 develop 里面，而后删除该分支，切换回 develop. 到此，新功能开发这个场景完毕。在 f1 功能开发中，若是 f1 未完成，同时功能 f2 要开始进行，也是能够的。

##2.2 场景2：发布上线，代号 0.1##

1. 基于develop，开发发布分支

➜ git flow release start 0.1
Switched to a new branch 'release/0.1'

Summary of actions:
- A new branch 'release/0.1' was created, based on 'develop'
- You are now on branch 'release/0.1'

Follow-up actions:
- Bump the version number now!
- Start committing last-minute fixes in preparing your release
- When done, run:

git flow release finish '0.1'

2. git-flow 从 develop 分支建立一个新的分支 release/0.1，并切换到该分支下，接下来要作的就是修改版本号等发布操做。完成后：

➜ git flow release finish 0.1
Switched to branch 'master'
Merge made by the 'recursive' strategy.
 f1      |    1 +
 version |    1 +
 2 files changed, 2 insertions(+)
 create mode 100644 f1
 create mode 100644 version
Switched to branch 'develop'
Merge made by the 'recursive' strategy.
 version |    1 +
 1 file changed, 1 insertion(+)
 create mode 100644 version
Deleted branch release/0.1 (was d77df80).

Summary of actions:
- Latest objects have been fetched from 'origin'
- Release branch has been merged into 'master'
- The release was tagged '0.1'
- Release branch has been back-merged into 'develop'
- Release branch 'release/0.1' has been deleted

3. git-flow 会依次切换到 master develop 下合并 release/0.1 里的修改，而后用 git tag 的给当次发布打上 tag 0.1，能够经过 git tag 查看全部 tag：

➜ git:(master) git tag
0.1
0.2

##2.3 场景3：紧急 bug 修正，代号 bug1##

1. 基于master，开启热修复分支

➜ git flow hotfix start bug1
Switched to a new branch 'hotfix/bug1'

Summary of actions:
- A new branch 'hotfix/bug1' was created, based on 'master'
- You are now on branch 'hotfix/bug1'

Follow-up actions:
- Bump the version number now!
- Start committing your hot fixes
- When done, run:

git flow hotfix finish 'bug1'

2. git-flow 从 master 分支建立一个新的分支 hotfix/bug1，并切换到该分支下。接下来要作的就是修复 bug，完成后：

➜ git flow hotfix finish bug1
Switched to branch 'master'
Merge made by the 'recursive' strategy.
 f1 |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
Switched to branch 'develop'
Merge made by the 'recursive' strategy.
 f1 |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
Deleted branch hotfix/bug1 (was aa3ca2e).

Summary of actions:
- Latest objects have been fetched from 'origin'
- Hotfix branch has been merged into 'master'
- The hotfix was tagged 'bug1'
- Hotfix branch has been back-merged into 'develop'
- Hotfix branch 'hotfix/bug1' has been deleted

git-flow 会依次切换到 master develop 分支下合并 hotfix/bug1，而后删掉 hotfix/bug1。到此，hotfix 完成。

git-flow 的 feature release 都是从 develop 分支建立，hotfix support 都是从 master 分支建立。

#3 一种的经典分支管理规范#

如上图所示：

1. 最稳定的代码放在 master 分支上（至关于 SVN 的 trunk 分支），咱们不要直接在 master 分支上提交代码，只能在该分支上进行代码合并操做，例如将其它分支的代码合并到 master 分支上。

2. 咱们**平常开发中的代码须要从 master 分支拉一条 develop 分支出来**，该分支全部人都能访问，但通常状况下，咱们也不会直接在该分支上提交代码，代码一样是从其它分支合并到 develop 分支上去。

3. 当咱们须要开发某个特性时，须要从 develop 分支拉出一条 feature 分支，例如 feature-1 与 feature-2，在这些分支上并行地开发具体特性。

4. 当特性开发完毕后，咱们决定须要发布某个版本了，此时须要从 develop 分支上拉出一条 release 分支，例如 release-1.0.0，并将须要发布的特性从相关 feature 分支一同合并到 release 分支上，随后将针对 release 分支部署测试环境，测试工程师在该分支上作功能测试，开发工程师在该分支上修改 bug。

5. 待测试工程师没法找到任何 bug 时，咱们可将该 release 分支部署到预发环境，再次验证之后，均无任何 bug，此时可将 release 分支部署到生产环境。

6. 待上线完成后，将 release 分支上的代码同时合并到 develop 分支与 master 分支，并在 master 分支上打一个 tag，例如 v1.0.0。

7. 当生产环境发现 bug 时，咱们须要从对应的 tag 上（例如 v1.0.0）拉出一条 hotfix 分支（例如 hotfix-1.0.1），并在该分支上作 bug 修复。待 bug 彻底修复后，需将 hotfix 分支上的代码同时合并到 develop 分支与 master 分支。

对于版本号咱们也有要求，格式为：x.y.z，其中，x 用于有重大重构时才会升级，y 用于有新的特性发布时才会升级，z 用于修改了某个 bug 后才会升级。针对每一个微服务，咱们都须要严格按照以上开发模式来执行。

与Git Flow模型分支管理的区别点：

1. feature分支开发完成后，暂时不合并至develop，而是基于develop开启release分支，将feature分支合并到release分支，进行测试；

2. release分支测试经过后，部署到生产环境，将release分支代码合并到develop分支与master分支，并在master分支打一个tag；