Git Flow 工作流

Git Flow 简介

Git Flow 是构建在 Git 之上的一个组织软件开发活动的模型，是在 Git 之上构建的一项软件开发最佳实践。Git Flow 是一套使用 Git 进行源代码管理时的一套行为规范和简化部分 Git 操作的工具。

分支约定

Git Flow 有主分支和辅助分支两类分支。其中主分支用于组织与软件开发、部署相关的活动；辅助分支组织为了解决特定的问题而进行的各种开发活动。

主分支（长期分支）

master 可执行版本记录分支，上面的每个节点都是发布到线上的一个版本，具体的版本号由 tag 确定
develop 代码开发分支，所有开发

辅助分支（短期分支）

feature 详细功能分支，每个功能分支应该尽可能的小（最好一天以内），开发完成之后尽快移入仓库中
release 测试版本发布分支，同时接收该版本的 bugfix，直到稳定之后再发布到 master，并合并到 develop 中。
hotfix 紧急修复线上 bug 分支，直接从 master 的版本分出，同时最小版本号加 1。修复完成后发布一个最新版本，同时合并到 develop 中。
主分支

主分支是所有开发活动的核心分支。所有的开发活动产生的输出物最终都会反映到主分支的代码中。主分支分为master分支和develop分支。

master 分支

master 分支存放的是随时可供在生产环境中部署的稳定版本代码
master 分支保存官方发布版本历史，release tag 标识不同的发布版本
一个项目只能有一个 master 分支
仅在发布新的可供部署的代码时才更新 master 分支上的代码
每次更新 master，都需对 master 添加指定格式的 tag，用于发布或回滚
master 分支是保护分支，不可直接 push 到远程仓 master 分支
master 分支代码只能被 release 分支或 hotfix 分支合并

develop 分支

develop 分支是保存当前最新开发成果的分支
一个项目只能有一个 develop 分支
develop 分支衍生出各个 feature 分支
develop 分支是保护分支，不可直接 push 到远程仓库 develop 分支
develop 分支不能与 master 分支直接交互
辅助分支

辅助分支是用于组织解决特定问题的各种软件开发活动的分支。辅助分支主要用于组织软件新功能的并行开发、简化新功能开发代码的跟踪、辅助完成版本发布工作以及对生产代码的缺陷进行紧急修复工作。这些分支与主分支不同，通常只会在有限的时间范围内存在。

辅助分支包括：

用于开发新功能时所使用的feature分支
用于辅助版本发布的release分支
用于修正生产代码中的缺陷的hotfix分支

以上这些分支都有固定的使用目的和分支操作限制。从单纯技术的角度说，这些分支与 Git 其他分支并没有什么区别，但通过命名，我们定义了使用这些分支的方法。

feature 分支

使用规范：

命名规则：feature/*
develop分支的功能分支
feature 分支使用develop分支作为它们的父类分支
以功能为单位从develop拉一个feature分支
每个feature分支颗粒要尽量小，以利于快速迭代和避免冲突
当其中一个 feature 分支完成后，它会合并回develop分支
当一个功能因为各种原因不开发了或者放弃了，这个分支直接废弃不影响develop分支
feature 分支代码可以保存在开发者自己的代码库中而不强制提交到主代码库里
feature 分支只与 develop 分支交互，不能与 master 分支直接交互

如有几个同事同时开发，需要分割成几个小功能，每个人都需要从develop中拉出一个feature分支，但是每个feature颗粒要尽量小，因为它需要我们能尽早merge回develop分支，否则冲突解决起来就没完没了。同时，当一个功能因为各种原因不开发了或者放弃了，这个分支直接废弃，不影响develop分支。

release 分支

使用规范：

命名规则：release/*，“*”以本次发布的版本号为标识
release分支主要用来为发布新版的测试、修复做准备
当需要为发布新版做准备时，从 develop 衍生出一个release分支
release分支可以从develop分支上指定commit派生出
release分支测试通过后，合并到master分支并且给 master 标记一个版本号
release分支一旦建立就将独立，不可再从其他分支 pull 代码
必须合并回develop分支和master分支

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

当develop分支上的代码已经包含了所有即将发布的版本中所计划包含的软件功能，并且已通过所有测试时，我们就可以考虑准备创建release分支了。而所有在当前即将发布的版本之外的业务需求一定要确保不能混到release分支之内（避免由此引入一些不可控的系统缺陷）。

成功的派生了release分支，并被赋予版本号之后，develop分支就可以为“下一个版本”服务了。所谓的“下一个版本”是在当前即将发布的版本之后发布的版本。版本号的命名可以依据项目定义的版本号命名规则进行。

hotfix 分支

使用规范：

命名规则：hotfix/*
hotfix分支用来快速给已发布产品修复 bug 或微调功能
只能从master分支指定 tag 版本衍生出来
一旦完成修复bug，必须合并回master分支和develop分支
master被合并后，应该被标记一个新的版本号
hotfix分支一旦建立就将独立，不可再从其他分支pull代码

除了是计划外创建的以外，hotfix分支与release分支十分相似：都可以产生一个新的可供在生产环境部署的软件版本。

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

这样做的显而易见的好处是不会打断正在进行的 develop 分支的开发工作，能够让团队中负责新功能开发的人与负责代码紧急修复的人并行的开展工作。

IDEA 安装 gitflow 插件

安装

前提你的电脑上需要安装了 git

idea -> file-settings -> Plugins -> marketplace- 搜索 Git Flow Integretion 安装重启 idea

点击IDEA右下角的No flow初始化分支

果出现 Gitflow 了，就表示完成了，可以使用

初始化插件设置建议勾选的设置

勾选配置说明：

Fetch from Origin （开启从远程拉取）
Push on finish feature（完成时自动推送）
Use custom tag commit message（使用自定义的打标签 commit message）

各工作流的执行样例

新功能开发 `feature`

点击 idea 右下角的 Gitflow -> Start Feature -> 填写新需求的简单描述 — ok

新生成的 feature 分支上编辑代码 -> 提交到本地（或者同时推送到远程）

新需求开发完成且提交到本地完成 -> 点击 Finish Feature

提测过程进行缺陷修改 -> 在该 release 分支上进行修改

Gitflow 插件会自动将该 release 分支的代码合并到 master 和 develop 分支（本地和远程），并自动删除 release 分支，与此同时会自动触发打 tag 的操作

tag 即表示一个版本，也就是合并一个分支到 master 都需要打一个 tag。

提测过程完成——由管理员操作执行点击Finish Releasea

注意：在提测未完成之前，严禁执行Finish Releasea！因为该操作会自动执行分支合并和删除的操作影响其他开发人员的工作

常规缺陷修复 `bugfix`

本地自测 bug 修复

点击 idea 右下角的 Gitflow -> Start Bugfix -> 填写bug信息并选择需要修复的develop分支

以 develop 分支自测发现了 bug，现在要对其进行修复为例

在 Bugfix 分支上 bug 修复完成后 -> 点击 Finish Bugfix 推送修改到本地 develop 分支
将本地 develop 分支推送到远程

注意：release分支上的缺陷修复也可以按照该流程执行

线上 bug 修复

修改线上 bug 的 hotfix 以 master 分支在运行时，出现了一个之前没有发现的 bug，现在要对其进行修复为例
点击 idea 右下角的 Gitflow -> Start hotfix
在 hotfix 分支上进行 bug 修复，提交到本地（可以一同推送到远程）
修复完成之后——点击 Finish hotfix gitflow 插件会自动将该 hotfix 分支的代码合并 master 和 develop 分支（本地和远程），并自动删除 hotfix 分支，与此同时会自动触发打 tag 的操作