GitFlow使用笔记

GitFlow理解

GitFlow 是由 Vincent Driessen 提出的一个 git操作流程标准，包含如下几个关键分支：
master：主分支，非常稳定的，不用来开发和发布，只用来跟踪已经发布的代码；
develop：主开发分支，包含确定即将发布的代码；开发都在这个分支；到发布时，再合并到release上；
feature：新功能分支，一般一个新功能对应一个分支，对于功能的拆分需要比较合理，以避免一些后面不必要的代码冲突；
release：发布分支，发布时候用的分支，测试时候发现的 bug直接 在这个分支进行修复；
hotfix：紧急修 bug 的时候用；

Git开发新功能

我们想在开发要开发一个新功能，基于develop分支创建feature分支

GitFlow开发完成合并

完成后再合并到 develop 分支上，等待发布。

GitFlow 发布

当需要发布时，我们从 develop 分支创建一个 release 分支
然后这个 release 分支会发布到测试环境进行测试，如果发现问题就在这个分支直接进行修复。

GitFlow发布结束时

发布结束后，这个 release 分支会合并到 develop 和 master 分支，从而保证不会有代码丢失

GitFlow 修复bug

hotfix 分支的作用是紧急修复一些 Bug。它们都是从 master 分支上建立，修复结束后再合并到 develop 和 master 分支上。

GitFLow 的优点

并行开发：
每个新功能都会建立一个新的 feature分支，从而和已经完成的功能隔离开来，而且只有在新功能完成开发的情况下，其对应的 feature分支才会合并到主开发分支（develop分支）

协作开发：
每个 feature分支多人协同开发。

发布阶段：
当 feature 开发完成的时候，它会被合并到 develop 分支，这个分支主要用来暂时保存那些还没有发布的内容，所以如果需要再开发新的 feature，我们只需要从 develop 分支创建新分支，即可包含所有已经完成的 feature 。

紧急修复：
hotfix（bug） 分支，这种类型的分支是从master分支上创建出来并做一个紧急的修复，而且这个紧急修复只影响这个已经发布的 版本，而不会影响到你正在开发的新 feature。

GitFLow 的缺点

GitFlow是通过规范的流程进行基线管理，避免需求开发与Bug修复、测试冲突；但是流程繁琐，在小团队中推行难度比较大，学习成本和维护成本高