IDEA插件实现GitFlow工作流管理

提示

本文参考一个成功的Git分支模型 (opens new window)作深化解释，若有兴趣可先阅读原文作适当了解。篇幅有限，以下内容不解释可能出现的代码冲突问题，这类问题有Git基础知识就能解决。

主要知识回顾

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