IDEA插件实现GitFlow工作流管理

IDEA 插件实现 GitFlow 工作流管理

本文参考一个成功的 Git 分支模型作深化解释，若有兴趣可先阅读原文作适当了解。篇幅有限，以下内容不解释可能出现的代码冲突问题，这类问题有 Git 基础知识就能解决。
在线文章：IDEA 插件实现 GitFlow 工作流管理

主要知识回顾

1、GitFlow 的核心分支

GitFlow 中的核心分支有两个，总结如下：

分支	特点
master ：主要面向用户，反映生产就绪状态(即正在被使用)。	一个个大版本，功能基本稳定，不存在未开发的阶段性小功能，也不存在已知 Bug，但可能存在未知 Bug。
develop：主要面向开发，反映下一个版本中最新交付的开发更改的状态(即跟当前 master 相比会有一些新的功能)。	不断地完成各种阶段性小功能，并一定时间后集成到 master 成为大版本。存在已知 Bug，但集成到 master 前必须修复。

当前关系如下图：

以上结构是否存在问题呢？

① 新的需求直接在develop上开发吗？怎么处理多人协同开发的问题呢？

② master的代码直接从develop合并吗？develop存在 bug 怎么处理？

③ master上存在 bug 怎么办呢？直接在develop上修改吗？

很明显，如果无论是需求还是测试 bug（develop）或线上 bug（master），如果都集中在develop去处理，那该分支的压力无疑是巨大的。从“解耦”的角度来看，有没有可能“专事专办”呢？当然！！！

2、GitFlow 的支撑分支

不绕关子，以上问题的解决办法直接列举如下：

① 新的需求不在develop上直接开发，而是从develop分离出需求类分支来实现，且为了方便测试，最好一个需求一个新分支。

② 大版本代码不从develop直接合并，而是从develop合并到发布类分支来操作，以方便测试人员做测试。

③ master上存在的 bug，一般的处理方式是直接从master提取出 bug 分支，修复后同时更新到develop和master。

关于 ③，如果只更新master而develop没有相应的修复，则新的大版本发布时，会因为master上存在 develop不包含的代码而产生冲突。

如上，我们可以设计出 3 个新的分支来实现：

分支	特点
feature：专注开发新需求。	一个需求一个 feature。
release：专注集成新开发的功能。	测试在这里进行，master 从这里获取大版本。
hotfix：专注修复线上 bug。	需要develop和master两头更新。

当前关系更改如下图：

根据图中数字，基本可以熟悉整个流程了：

• 1-开发人员从develop分支按功能分离出feature，完成后又合并回develop。
• 2-一定开发进度完成后develop合并到release。
• 3-测试人员测试release中的代码，有问题则通知开发人员分离bugfix进行修复后再合并。
• 4-测试人员测试release中的代码，没问题后通知开发人员将release合并到master进行大版本发布。
• 5-用户使用过程中出现系统 bug，开发人员从master分理出hotfix进行修复。
• 6-开发人员修复好的hotfix分别更新到develop和master。

上面提到了 bugfix，其本质也是跟 hotfix 一样为了修复 bug 而存在的，区别只在 bug 发现于线上还是线下。这也说明了支撑分支并非固定不变的，包括数量和命名都可以根据实际开发需求灵活变动。

以上，我们已经从概念上说完了 GitFlow 的核心知识点，下面就从 IDEA 插件的角度来看看具体如何实现相应的工作流。

使用 Git 管理项目（依托 Gitee）

1.创建项目：

2.创建 Gitee 仓库：

3.将创建好的项目和仓库关联：

4.现在，你的远程仓库和你本地的项目就有了关联，但目前只有master分支：

5.在 Gitee 仓库中，基于master分支创建develop分支，这样，后者就会完全拷贝前者的内容：

6.同样，在本地，我们也基于master分支创建develop分支，或者你也可以直接从远程的gitflow-demo/develop分支签出（Checkout），效果是一样的：

7.这样，最终你就有了四个内容一模一样的分支，远程和本地各两个，分别为：远程的gitflow-demo/master和gitflow-demo/develop、本地的master和develop：

以上就是 GitFlow 的核心分支，其作用已在上文说明。关于master和develop，使用过 Git 的朋友应该是再熟悉不过了，这里就不再赘述，下面开始介绍 GitFlow 插件。

Git Flow Integration 插件的使用

1.插件市场直接搜索【Git Flow Integration (Plus)】安装：

2.重启 IDEA 后，右下角窗口就会出现该插件的相应视窗：

• No Gitflow：表示该插件已安装，但当前项目仍未被管理
• Init Repo：对当前项目仓库进行初始化，以便执行相应的管理流程

3.点击 【Init Repo】 对项目仓库进行初始化。

初始化仓库前，必须保证本地和远程分支内容一致，不存在未同步的部分，否则无法初始化。

初始化选项中，有很多前面提到过的内容，这里简单复述重点，以便熟悉掌握：

• Use non-default configuration：表示使用非默认配置，可以自定义分支名称。强烈推荐默认不更改，便于与团队成员交流，因为大家都熟悉默认的名称。
• 生产分支，面向用户：master
• 开发分支，面向开发：develop
• 特性分支，专注需求：feature
• 发布分支，集成发布：release
• 修补分支，修复线上 Bug：hotfix
• 支撑分支，拓展支撑：support（新）
• 漏洞分支，修复线下 Bug：bugfix（新）
• Version tag：给当前初始化起个标签，非必要也建议默认不填。

Git Flow 原文并未提及support和bugfix，但这并不奇怪，上文及对原文的解析篇都提到过，分支是可以拓展的。

support可以看成是feature的延伸，做一些特定的需求或支撑工作。

bugfix可以看成是hotfix的补充，专注于测试人员提出的 Bug。

4.初始化完毕后，Gitflow 视窗如下图所示，每一个 Start 都表示创建新的对应分支：

5.根据相应需求创建feature分支。以两个特别简单的需求为例：

① 创建一个类 A，输出“中秋快乐！！！”，由程序员甲开发

② 创建一个类 B，输出“新年快乐！！！”，由程序员乙开发

综上，从develop分离出两个feature分支并交由相应的程序员来开发对应功能，完成后整合回develop。

参考如下操作过程：

(1)从develop分离出（Start Feature）第 1 个feature分支，填写相应的名字

注：因为此时develop和master一致，所以也能从master分离，默认是develop

出现以上信息说明第 1 个feature分支已经创建成功了。

(2)从develop分离出第 2 个feature分支，填写相应的名字

这样，第 2 个feature也创建好了。

6.创建release分支，方便后续整合开发好的阶段性功能：

步骤 5 创建好的两个feature分支，还没有相应的release，这里创建：

这样，我们就有了以下的标准初始化分支：

7. 开发相应的功能：

跟普通 Git 一样，切换到相应的分支用【Checkout】命令即可：

我们分别在“中秋快乐”和“新年快乐”两个分支下开发相应的需求功能：

(1)“中秋快乐”分支下的代码：

提交到仓库：

(2)“新年快乐”分支下的代码：

提交到仓库：

8.将开发好的功能整合到develop分支：

(1)切换到develop分支，选择feature/中秋快乐，执行操作【Merge ‘feature/中秋快乐’ into ‘develop’】，该操作将feature/中秋快乐合并到develop，这样代码就到了develop中。

以上操作一定要细心，操作错误会导致不必要的麻烦。

上图是操作成功的效果。

合并代码到develop，成功后出现了【Delete feature/中秋快乐】的链接，表示可以删除该分支了。为防止后续可能还用到该分支，这里暂时不删。

(2)继续将feature/新年快乐整合到develop，和步骤(1)是同样的操作，不再赘述。

上图是操作完成后远程仓库的效果。

9.将develop分支合并到release分支，供测试和待发布：

(1)切换到创建好的release/Release1分支：

(2)将develop分支合并到release/Release1分支：

(3)最后将release/Release1分支提交到远程仓库，未有该分支将直接创建：

(4)至此，我们远程仓库就有了第 1 个发布分支release/Release1：

10.演示Bugfix的作用：

(1)现在，我们的release/Release1有了 ZhongQiu.class 和 XinNian.class 两个类，可以调用它们的方法了：

但是，测试人员发现，“ZhongQiu.print()”这个方法只输出了一个感叹号，与需求不符，产生了线下bug，于是反馈给了开发人员……

(2)开发人员检查后发现……好吧，确实出现了bug，难搞~~~于是开始修复操作，有两种办法可以采用：

①因为featrue/中秋快乐分支未删除，可以直接在该分支修改后合并到develop和release/Release1即可。这解释了上面为啥没有直接删除该分支，最合适的删除时间是在确定该分支代码已无任何问题之后。

②从release/Release1分支分离出Bugfix类分支来修改，修改完后合并到develop和release/Release1。此时featrue/中秋快乐分支已无实际用处，可删除。

需要合并到develop的原因是，保证此次线下bug在后续的发布也不会出现，因为后续发布的代码从develop继续合并。

(3)开始代码修复工作，首先创建相应的bugfix分支：

(4)更改代码后提交：

(5)切换到develop后，选中刚刚的bugfix（包含了已经改好的代码），再通过【Merge …… into develop】将代码合并到develop。注意按步骤走，先切后选再合并：

操作完成后，记得将相应的代码更新到远程仓库。

(6)同理，也是先切后选再合并，将修复合并到release/Release1，最后更新远程仓库：

以上截图可能略显重复臃肿，但对于理解合并修复很有帮助，细品。

(7)下面，是远程仓库gitflow-demo/develop和gitflow-demo/release/Release1的截图，很明显，修复已更新：

11.正常发布过程，即发布分支 release 合并到 master 并更新到用户服务器：

(1)切换到gitflow-demo/master

(2)将相应的gitflow-demo/release/Release1合并，之后在服务器中更新就可以啦~（更新略……）

12.演示Hotfix的作用：

前文强调过，Hotfix和Bugfix很类似，区别在于 bug 出现的时间点（线上线下），以及分支的分离点（develop和master）。

(1)用户反馈应该输出“新年快乐！！！”但少了两个“！！”，开发人员确认后从master分离分支：

(2)切换到相应的Hotfix，修复代码并提交：

(3)切换到develop，并合并提交：

(4)切换到master，并合并提交：

(5)在服务器上更新master，相应的线上bug就被修复了。（更新略……）

以上，便是 GitFlow 的一个完整管理流程。

总结

1. GitFlow 本身是 Git 的拓展和延伸，是为了更方便开发和管理项目所提出的，其本质还是 Git。
2. GitFlow 灵活性较高，这点跟 Git 一样，可以根据自身需求来实际使用，不必过分契合分支模型。
3. 最后再放一下模型，请深入理解，灵活运用：