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. 最后再放一下模型，请深入理解，灵活运用：