Gitflow 使用

1. 概述

如果你严肃对待编程，就必定会使用版本管理工具，而 Git 是当下最流行的版本管理系统，Git 操作是基于分支的，当下环境衍生出多种优秀的分支管理策略，其目的就是要保证不同分支各司其职，避免多人协作过程中代码冲突、代码版本出现问题。在日常迭代过程中，每个公司都有一套自己的分支管理规范，但万变不离其宗，都有 Gitflow 的影子。

2. Gitflow 工作流程

2.1. Gitflow 关键分支

分支名称	分支说明	分支时效	环境
master	与线上环境运行代码版本一致，需保证最高稳定性 • 只⽤于存放所有的发布 • 每次有了新的 commit 之后，⽴即打⼀个 tag 来记录	永久分支	线上生产环境
develop	开发过程中操作分支（开发阶段） • develop 在第⼀时间从 master 上分离出来 • develop 并不是直接⽤于开发 feature 的，开发 feature 需要单独创建对应的 feature-branch • 当下⼀正式版本需要的所有功能开发完成之后，从 develop 上创建新的 release branch，并在 release branch 合并到 master 后合并回 develop（合并的时候⽤ --no-ffff），然后删掉 release branch	永久分支	开发环境
feature	新功能分支，一般一个新功能对应一个 feature 分支，以避免后面一些不必要的代码冲突 • 每次开发新功能是从 develop 创建 • 开发完成后合并到 develop（使⽤ --no-ff），然后被删掉	临时分支
release	亦或者叫 bugfix 分支，修复测试环境 Bug 所用分支，建议一个 Bug 单独切一个分支，(测试阶段) • 每次下⼀版本的功能开发完毕后，从 develop 上创建 • 创建完成后，更新版本号，然后单独做⼀个新的 commit • 如果有 bug fix，直接在 release branch 上创建 • bug fix 完成后，合并到 master 和 develop（使⽤ --no-ff），然后被删掉	临时分支	测试环境/压测环境/预生产环境
hotfix	紧急修复线上 bug 的时候使用的分支 • 已正式发布的产品发现 bug，直接从 master 或者出问题的 tag 上创建 hotfix branch，进⾏紧急修复， • 修复完成后合并到 master 和 develop（或 release branch 如果有的话）（使⽤ --no-ff），然后被删掉	临时分支

Gitflow 流程图：

• master 与 develop

这张图涉及内容较多，我们只需要关注两个分支，一个是 master 分支，另一个是 develop 分支，通过箭头可以看到，develop 分支是基于 master 分支创建，在提交代码后，又重新回到了 master 分支，这里体现的是，在迭代开始前，需要基于线上代码最新版本合并到开发分支，作为团队成员开发的公共分支。在使用 Git 时，需要遵循一个原则：从哪里来，最后回到哪里去。

• develop 与 feature

接下来我们需要关注的是 feature 分支与 develop 分支。在团队协作过程中，对于需求的开发，通常是采用一个成员负责一个功能点或者模块，那么就需要不同成员往 develop 分支提交代码，即需要从develop 分支创建 feature 分支开发新功能，编码自测完成后，再从 feature 分支 push（推送）到 develop 分支，这同样遵循了以上规则。

• develop 与 release

在企业开发中，每次迭代往往定义一个版本号，release 分支与之对应。随时间线推进，到达迭代开发中的提测阶段，则需要将开发的新代码从 develop 分支推送到 release 分支，而后发布代码 (CI/CD) 到测试环境供测试验证。

• release 与 bugfix

当测试提出缺陷时，似乎我们需要排查一下自己代码中是否存在问题。如果是，那么我们需要基于测试环境的 release 分支代码版本做修改，此时，我建议基于 release 分支去创建一个 bugfix 分支用于修复代码中的问题。修复完毕后再将bugfix分支的代码推送到 release 分支，push 完成后，将 bugfix 分支删除，确保一个 bugfix 分支只做一件事。

• release 与 master

测试完成、熬到上线、喜大普奔。上线时需要将 release 分支代码推送到 master，同样的道理，在推送前需要将 master 分支代码更新到最新版本，release 分支合并 master 分支代码，再切换到 master 分支合并 release 分支代码。

• master 与 hotfix

当生产环境用户反馈了一个问题，确认为代码缺陷时，需要基于最新的 master 分支创建 hotfix 分支去修复线上 bug，修复完毕后，从 hotfix 分支按上述 release 分支推送到 master 分支流程推送代码到 master 分支即可。

2.2. Gitflow 使用示例

2.2.1. 使用 Git 按 Gitflow 工作流程工作

feature branch 使用示例：

// 先切换到 develop 分支，保持 develop 代码最新
git checkout develop
// 创建一个新功能分支
git checkout -b feature_branch
// 完成功能的开发工作后，下一步就是将 feature_branch 合并到 develop 中
git checkout develop
git merge --no-ff feature_branch
 
...
 
// 一个阶段的所有新功能开发完成
git checkout develop
git checkout -b release/0.1.0
// 准备好发布，合并 release/0.1.0 到 master 和 develop，然后删除 release/0.1.0 分支
git checkout master
git merge release/0.1.0
git checkout develop
git merge release/0.1.0
 
...
 
// master 分支打 tag
git tag 0.1.0
// 推送 tag
git push origin 0.1.0

2.2.2. 使用 Gitflow 扩展库

feature branch 使用示例：

// mac 使用  brew 下载扩展库 'brew install git-flow-avh'
// 分支名称推荐使用 git flow 默认命名方式
git flow init
// 创建一个新功能分支
git flow feature start feature_branch
// 完成功能的开发工作后，下一步就是将 feature_branch 合并到 develop 中
git flow feature finish feature_branch
 
...
 
// 一个阶段的所有新功能开发完成
git flow release start 0.1.0
// 准备好发布，合并 release/0.1.0 到 master 和 develop，然后删除 release/0.1.0 分支
git flow release finish '0.1.0'
 
...
 
// git flow 自动创建 tag 0.1.0
// 推送 tag
git push origin 0.1.0

2.3. 版本号说明

• 版本号格式 0.0.0 ~ 999.999.999，最后一个为热修复版本号，中级位是日常新功能迭代版本号，首位为重大事件版本号
• master 分支上打 tag，不带 “v” 或者 “V”，只使用数字和”.“

2.4. 其它

• 分支命名使用 ”-“ （例如 feature-branch）官方推荐使用“-”，但遵循不同团队使用习惯可以使用 “_”

3. 参考文档

原文链接

Gitflow Workflow