主要内容

1.git flow 原理

• 两个永久分支
• 三个工作分支
• feature 分支
• Release 分支
• Hotfix 分支

2.Git flow 插件和 jgitflow 插件

1.git flow原理

原理请参考：https://nvie.com/posts/a-successful-git-branching-model/

1.1 两个永久分支

master 分支：
与生产的版本对应，所有生产的版本只能来自 master 分支。所以 master 分支要么与生产环境的版本一致，要么包含了已经完成所有测试验证的、待发布的特性。不能直接手工在 master 分支提交内容，只能通过git flow 插件操作。

develop 分支：
develop 分支最初来自 master 分支，后面独自演进。开发分支包含下一次发布版本需要版本的特性。这些特性都还没有经过测试。通常不能直接手工在 master 分支提交内容，只能通过git flow 插件操作。

也就是说 master 和 develop 分支不是我们日常开发和测试的工作分支。

1.2.三个工作分支

Git flow 包含三种支持工作的分支。这三种支持分支是为了满足开发过程中的三种主要的工作场景设计的。支持分支是临时分支，当工作完成，支持分支使命就完成了，就应该删除。

feature 分支
主要的开发工作分支，用来开发新特性

release 分支
开发完成后，转测拉取的分支，是开发和测试的工作分支，测试基于这个分支做测试，开发在这个分支修复测试发现的 bug。

hotfix 分支
也是开发和测试的工作分支，开发在这个分支修生产环境发现的 bug，开发基于这个分支测试验证生产发现的 bug 是否已经修复

1.3 feature 分支

Feature 分支源是从 develop 分支拉取的。当我们需要实现一个新的功能特性的时候，都是从 develop 拉取一个新的 feature 分支，并且一直基于这个 feature 分支做开发工作。

当我们认为特性已经完成，并且完成的特性是下一个规划的版本的内容的时候，就可以将在 feature 分支开发的代码合并回 develop 分支，等待下个版本规划的内容全部完成后转测。

比如我们有个特性叫 demo 需要开发可以做如下操作：

#从开发分支拉取 demo 特性分支，feature 分支的命名规范为 feature-*
$git checkout -b feature-demo develop
Switched to a new branch 'feature-demo'
 
#开发在feature 分支开发新功能
$ git checkout develop
Switched to branch 'develop'
#......经记过一段时间，多次提交后完成开发工作
 
#把 feature 分支的工作合并到 develop
$ git merge --no-ff feature-demo
Updating ea1b82a..05e9557
(Summary of changes)
 
#featrue 分支的使命已经完成，删除。如果feature 分支已经提交到远程代码库，则还需要从远程代码库中删除
$ git branch -d feature-demo2
Deleted branch feature-demo2(was 05e9557).
$ git push origin develop

1.4 Release 分支

Release 分支也是从 develop 分支拉取的,用于支持一个新的生产版本的发布。当一个规划的版本的所有特性都已经开发完成，并且都已经合并回 develop 的时候。从develop 拉取分支，测试基于该分支测试，开发修复bug.
当除了标记以后版本修复的 bug外，所有bug 已经修复，并且所有规划功能已经完备的时候，将这个release 合并到develop 和 master。这样master 分支就具备了计划发布的功能，同时在release 针对bug 的修复也合并到了 develop 分支。Release 分支的命名规范release-*。

例如规划的版本2.2 的特性已经全部开发完成，合并到了develop 分支。转测步骤如下：

$git checkout -b release-2.2 develop
Switched to a new branch 'release-2.2'
#java 工程还需要将开发分支的 pom.xml 中的版本修改为 2.3-SNAPSHOT，这样开发团队可以在转测后，继续下个迭代版本的开发
 
#测试基于release 分支测试，开发修复bug，所有工作完成后，将pom.xml 版本去掉 SNAPSHOT 改为 2.2, 并提交代码。
将release 合并到master ，并准备发布版本 tag
$ git checkout master
Switched to branch 'master'
$ git merge --no-ff release-2.2
Merge made by recursive.
(Summary of changes)
$ git tag -a v2.2
 
#将release 合并到develop，保证release 分支期间的bug 修复都应用到develop 分支
$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff release-2.2
Merge made by recursive.
 
#release 分支的使命已经完成，删除
$git branch -d release-2.2
Deleted branch release-2.2 (was 6cc76e7).
(Summary of changes)

1.5 Hotfix 分支

通常应该是从 master 分支，用于支持修改生产环境的bug，做生产发布。当生产发现紧急bug，不能等到下次发版，必须尽快修复的时候。从master 上的某个tag 拉取分支，开发修复bug，测试基于该分支测试验证。

当确认bug 已经修复的时候，将修改内容同步到master 和 develop分支，然后删除分支。命名规范，hotfix-*。

注意：当前如果存在一个 release 分支的时候，应该合并到 release 分支，而不是 develop 分支。因为该版本正在测试，可以避免测试提出相同的bug，另外可以验证新开发的 feature 与所做的 hotfix 修复的叠加是否会引入新的 bug。如果直接同步到 develop，就可能导致不能在当前转测发布的版本中发现叠加引入的 bug。

例如生产的版本是 2.2，发现了必须紧急修复的bug，操作如下：

$git checkout -b hotfix-2.2.1 master
Switched to a new branch 'hotfix-2.2.1'
#java 工程先将 pom.xml 版本修改为 2.2.1-SNAPSHOT
 
#开发基于hotfix 修复bug，测试验证。验证通过，将 pom.xml 版本去掉SNAPSHOT 改成 2.2.1
#代码都已经提交到hotfix 分支后。将hotfix 合并到master ，并准备发布版本 tag
$ git checkout master
Switched to branch 'master'
$ git merge --no-ff hotfix-2.2.1
Merge made by recursive.
(Summary of changes)
$ git tag -a v2.2.1
 
#将hotfix  合并到develop，保证hotfix 分支期间的bug 修复都应用到develop 分支
$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff hotfix-2.2.1
Merge made by recursive.
 
#hotfix 分支的使命已经完成，删除
$git branch -d hotfix-2.2.1
Deleted branch hotfix-2.2.1 (was 6cc76e7).
(Summary of changes)

2.Git flow 插件和 jgitflow 插件

Jetbrain 下 git flow 插件下载安装，可以参考

https://plugins.jetbrains.com/plugin/7315-git-flow-integration

注意目前插件只支持 build 202*

通常前端同学应该考虑用Git flow 插件，要么是 Jetbrain的插件，其他的主流开发IDE 也应该有相应的插件。要么是git 命令行的插件，通过 git flow 命令的方式来实现上述的过程。

Jetbrain 下 git flow 插件使用，可以参考：https://www.jianshu.com/p/2bad1d6062ec

git flow 命令安装，请参考：https://github.com/nvie/gitflow/wiki/Installation

对于 java 同学，毫无疑问，肯定是使用 maven 插件，具体如下：

<plugin>
    <groupId>external.atlassian.jgitflow</groupId>
    <artifactId>jgitflow-maven-plugin</artifactId>
    <version>1.0-m3</version>
    <configuration>
        <!-- see goals wiki page for configuration options -->
        <flowInitContext>
            <masterBranchName>master</masterBranchName>
            <developBranchName>develop</developBranchName>
            <featureBranchPrefix>feature-</featureBranchPrefix>
            <releaseBranchPrefix>release-</releaseBranchPrefix>
            <hotfixBranchPrefix>hotfix-</hotfixBranchPrefix>
            <versionTagPrefix>v</versionTagPrefix>
        </flowInitContext>
    </configuration>
</plugin>

可以直接在 IDE 的 mavn 工具栏中快捷操作。

也可以通过命令行的方式:

mvn jgitflow:feature-start
mvn jgitflow:feature-finish
mvn jgitflow:release-start
mvn jgitflow:release-finish
mvn jgitflow:hotfix-start
mvn jgitflow:hotfix-finish

注意：

git flow 不会将支持分支推送到我们的私服代码库，我们应该通过手工命令确保推送到代码库，虽然支持分支都是临时的，但是为了避免开发过程，本机出现问题，或者致辞多个同事合作完成一个工作。

命令为：git push --set-upstream origin feature-demo

支持分支删除后，git flow 不会删除远程分支， 可能会导致使用 mvn jgitflow 插件拉分支时误判存在相关远程分支而中断，随诊时间的积累，会存在非常多的远端分支，增加代码版本管理的负担。可以通过 git branch -r来查看刚刚删除的支持分支是否在远端存成，如果存在可以通过命令 git fetch -p 来删除相关远程分支