GitFlow简明教程
一、简介
GitFlow是最早诞生并得到广泛采用的一种Git工作流程，它主要包含两个长期分支和三个短期分支，在这些分支的基础上，能满足大多数的协同开发工作。
二、长期分支
2.1 master
master是主要分支，在创建代码库的时候默认就存在的，它承担着对外发布版本的职责，所以也要求其分支上的代码必须是稳定可靠的。每一个将要发布的版本都被打成一个tag，长期下来，master分支就是如下这个样子的，当需要使用某个具体的版本时，直接拉取相应版本的tag即可。
master分支
2.2 develop
develop分支是日常开发中积聚版本功能使用的，工程师总是把自己的代码合并到这个分支。经过一段时间和一定功能的积累后，就将develop分支上的内容合并到master上进行发布。它和master分支的关系如下图所示。
develop分支
develop分支并不是初始就有的，需要自己创建：
git checkout -b develop master
上述命令的意思是基于master分支创建一个名为develop的分支，并且切换到develop分支上。
当develop分支上积聚够了一个版本的内容后，可以使用如下命令将需要发布的内容合并到master分支上去：
git checkout master
git merge develop
上述命令第一步是先切换到master分支上，然后在master分支上合并develop分支上的内容，如此就完成了一个版本代码的合并。如果此时确定不需要再增加或者修改内容的话，可以给master分支当前的状态打个tag，比如：
git tag Version0.4
如此，我们就在master上新打了一个名称为“Version0.4”的tag。
三、短期分支
2.3 feature
feature分支是给各个开发人员提交自己代码使用的，每个人针对每个功能都应该新建一个相应的feature分支，然后在该分支上持续提交代码，直至这个功能完成开发。
在一个版本的开发之初，我们应该从develop分支上创建自己的feature分支：
git checkout -b feature-xxx develop
当我们开发完成后需要合并到develop分支时，执行以下操作：
git checkout develop
git merge feature-xxx
当确认无需增加和优化该功能后，删除该特性分支，继续下一个特性分支的开发即可：
git branch -d feature-xxx
feature分支与develop分支的关系如下图所示：
feature分支
2.4 release
有的时候，我们可能需要对本次版本的内容进行预发布，再根据预发布的情况做出细微的更改。
这个时候，develop分支可能已经开始下个版本内容的开发了，所以肯定不能用了，master分支又是不允许直接提交修改内容的，因此我们需要从develop上新建一个release分支，用于满足预发布的需求。
git checkout -b release-xxx develop
等到预发布确认不再需要增加或者修改内容后，需要将修改的内容同时合并到master和develop分支:
git checkout master
git merge release-xxx
git tag Version0.5
git checkout develop
git merge release-xxx
git branch -d release-xxx
如果需要的话，各个开发工程师也可以将更改的内容更新到自己的特性分支上：
git checkout feature-xxx
git pull
此时，就可以继续安心地开发了。
2.5 fixbug
版本发布后，有可能会发现Bug，这个时候，develop分支可能已经合并了下个版本中其它feature分支的内容，很明显不能在develop分支上修复Bug，再合并到master上，因为会把下个版本的内容提前发布到生产环境。这个时候，就需要基于master分支创建一个fixbug分支：
git checkout -b fixbug-xxx master
等到问题全部修复完成，再将当前分支的内容分别合并到master和develop上。同时，如果要使用master上的内容重新发布的话，再打一个tag，等到最后，再将这个fixbug分支删除：
git checkout master
git merge fixbug-xxx
git tag Version0.6
git checkout develop
git merge fixbug-xxx
git branch -d fixbug-xxx
fixbug分支与master和develop分支之间的关系如下图：
fixbug分支
此时，各位开发工程师的特性分支最好能够从develop分支上将该Bug的修复内容更新下来：
git checkout feature-xxx
git pull
此时，就可以继续安心地开发了。
四、优缺点分析
4.1 优点
- 各个分支的作用都很清晰明确，能应付复杂的多人协作场景。
4.2 缺点
- 分支数目多，操作略微复杂，各个分支之间的切换很是繁琐，不能满足持续发布的场景。
- 某个已发布的稳定版本不支持在不增加内容的情况下修复Bug，这个GitLabFlow就可以支持。
