1.GitFlow的由来

在使用Git的过程中如果没有清晰流程和规划，否则,每个人都提交一堆杂乱无章的commit,项目很快就会变得难以协调和维护。Git版本管理同样需要一个清晰的流程和规范。

我们为什么需要GitFlow这种git管理流程？原因有以下几点

有一个稳定版本的代码分支，可以安心的用在线上发布。

在代码提测前或者说是代码达到预发状态时，在测试交付的过程中程序员们还可以继续进行下一个版本的开发工作（挤出每一秒去开发-_-’’）。

有个一个分支可以让我们及时的对线上的bug进行修复，这个过程中我们不希望将正在开发中的代码提交到线上生产中去。

由于上述开发过程中面临的需求，GitFlow协同工作流应运而生。对应的点就是

代码共享

不同环境下代码互不干扰

管理好代码与环境的一致性

2.GitFlow的图示

Git Flow 的常用分支：

Production 分支

也就是我们经常使用的Master分支，这个分支最近发布到生产环境的代码，最近发布的Release， 这个分支只能从其他分支合并，不能在这个分支直接修改

Develop 分支

这个分支是我们是我们的主开发分支，包含所有要发布到下一个Release的代码，这个主要合并与其他分支，比如Feature分支

Feature 分支

这个分支主要是用来开发一个新的功能，一旦开发完成，我们合并回Develop分支进入下一个Release

Release分支

当你需要一个发布一个新Release的时候，我们基于Develop分支创建一个Release分支，完成Release后，我们合并到Master和Develop分支

Hotfix分支

当我们在Production发现新的Bug时候，我们需要创建一个Hotfix, 完成Hotfix后，我们合并回Master和Develop分支，所以Hotfix的改动会进入下一个Release

3.如何巧妙Git Flow进行团队开发

Master/Devlop 分支

所有在Master分支上的Commit应该打上Tag，一般情况下Master不存在Commit，Devlop分支基于Master分支创建

Feature 分支

Feature分支做完后，必须合并回Develop分支, 合并完分支后一般会删点这个Feature分支，毕竟保留下来意义也不大。

Release 分支

Release分支基于Develop分支创建，打完Release分支之后，我们可以在这个Release分支上测试，修改Bug等。同时，其它开发人员可以基于Develop分支新建Feature (记住：一旦打了Release分支之后不要从Develop分支上合并新的改动到Release分支)发布Release分支时，合并Release到Master和Develop， 同时在Master分支上打个Tag记住Release版本号，然后可以删除Release分支了。

Hotfix 分支

hotfix分支基于Master分支创建，开发完后需要合并回Master和Develop分支，同时在Master上打一个tag。

4.Git Flow的优点

• 适应场景多
• 不影响开发进度
• 分支使用相对有条理
• 确保线上的版本稳定