概况
通过利用Git创建和管理分支的能力，为每个分支设定具有特定的含义名称，并将软件生命周期中的各类活动归并到不同的分支上，实现了软件开发过程不同阶段的相互隔离。
流程
初始化 git flow 项目时 会默认创建一个 master 分支，然后从 master 分支拉取第一个 develop 分支 ，然后从 develop 分支拉取一个 feature分支，多个开发者可以拉取多个 feature 分支，同时并行的进行开发。
当我们feature分支功能开发完成后，我们可以合并到我们的 develop 分支。合并完成后我们可以删除当前的 feature 分支，如果不删除，当前的 feature 分支不可修改。
当我们所有功能都开发完成后，我们可以从develop 分支拉取一个 release 分支用于提测。如果要修改提测过程中的bug，必须在 release 分支上进行修改维护。当测试通过后，我们可以将 release分支上的代码合并到 develop 分支 和 master 分支。合并完后我们可以删除当前的 release 分支，如果不删除，当前的 release 分支不可修改。
当线上发现bug的时候，我们必须从 master 分支拉取 hotfix 分支进行bug的修复。hotfix分支通过测试上线后，将其合并到 master 分支和 develop 分支。合并完成后我们可以删除当前的 hotfix 分支，如果不删除，当前的 hotfix 分支不可修改。如果这时候上线还有bug，我们必须重新从 master 分支拉取一个新的 hotfix 分支进行一个 bug 修复。
当进行一个 feature 分支开发的时候，如果发现 develop 分支变动（其他开发完成了各自的功能开发，然后把自己的 feature 合并到 develop），这时我们就需要将develop 分支的代码合并到我们的 feature 分支。
同理，当进行一个 release 分支的时候，如果develop分支发生变动，我们必须将 develop 分支的代码合并到我们的 release 分支上。如果不合并可能发生代码丢失的情况。
Git Flow 分支说明
Git Flow 的核心就是分支（Branch），通过在项目的不同阶段对分支的不同操作（包括但不限于创建、合并、变基等）来实现一个完整的高效率的工作流程。
Git Flow 的分支主要分为两大类：主分支（长期分支） 和 辅助分支（短期分支）。
- 主分支包含：主要分支 master 和 开发分支 develop。
前者用于存放对外发布的版本，任何时候在这个分支拿到的都是稳定的发布版；后者用于日常开发，存放最新的开发版本
- 辅助分支包含：功能分支、预发分支、热修复分支以及其他自定义分支。
一旦完成开发，它们就会被合并进 develop和 master，然后被删除。
主要分支 Master
主要分支上存放的是最稳定的正式版本，并且该分支的代码应该是随时可在生产环境中使用的代码。当一个版本开发完毕后，产生了一份新的稳定的可供发布的代码时，主要分支上的代码要被更新。同时，每一次更新，都需要在主要分支上打上对应的版本号。
任何人不允许在主要分支上进行代码的直接提交，只接受其他分支的合入。原则上主要分支上的代码必须是合并自经过多轮测试及已经发布一段时间且线上稳定的预发分支。
开发分支 Develop
开发分支是主开发分支，其上更新的代码始终反映着下一个发布版本需要交付的新功能。当开发分支到达一个稳定的点并准备好发布时，应该从该点拉取一个预发分支并附上发布版本号。也有人称开发分支为集成分支，因为会基于该分支和持续集成工具做自动化的构建。
开发分支接受其他辅助分支的合入，最常见的就是功能分支，开发一个新功能时拉取新的功能分支，开发完成后再并入开发分支。需要注意的是，合入开发的分支必须保证功能完整，不影响开发分支的正常运行。
功能分支 Feature
功能分支一般命名为 Feature/xxx，用于开发即将发布版本或未来版本的新功能或者探索新功能。该分支通常存在于开发人员的本地代码库而不要求提交到远程代码库上，除非几个人合作在同一个功能分支开发。关于这点，Thought Works洞见上有一篇文章“Git Flow有害论”做了非常有意思的阐述，文章下的评论也异常激烈。也许该文章的名字可能有失偏颇，但文章的本意以及评论传达了一个观点：功能分支要求足够细粒度以避免成为长期存在的功能分支，应当小步合并而不是一次合并大量代码。
功能分支只能拉取自开发分支，开发完成后要么合并回开发分支，要么因为新功能的尝试不如人意而直接丢弃。
预发分支 Release
预发分支一般命名为 Release/1.2（后面是版本号），该分支专为测试—发布新的版本而开辟，允许做小量级的Bug修复和准备发布版本的元数据信息（版本号、编译时间等）。通过创建预发分支，使得开发分支得以空闲出来接受下一个版本的新的功能分支的合入。
预发分支需要提交到服务器上，交由测试工程师进行测试，并由开发工程师修复Bug。同时根据该分支的特性我们可以部署自动化测试以及生产环境代码的自动化更新和部署。
预发分支只能拉取自开发分支，合并回开发分支和主要分支。
热修复(补丁)分支 Hotfix
热修复分支一般命名为Hotfix/1.2.1（后面是版本号），当生产环境的代码（主要分支上代码）遇到严重到必须立即修复的缺陷时，就需要从主要分支上指定的tag版本（比如1.2）拉取热修复分支进行代码的紧急修复，并附上版本号（比如1.2.1）。这样做的好处是不会打断正在进行的开发分支的开发工作，能够让团队中负责功能开发的人与负责修复的人并行、独立的开展工作。
热修复分支只能主要分支上拉取，测试通过后合并回主要分支和开发分支。
评价
Git flow 的优点是 清晰可控，缺点是相对复杂，需要同时维护两个长期分支。
将这么一套复杂的流程应用到团队中，不仅需要每个人都能正确地理解和选择正确的分支进行工作，还对整个团队的纪律性提出了很高的要求。毕竟规则越复杂，应用起来就越难。
更大问题在于，这个模式是基于”版本发布”的，目标是一段时间以后产出一个新版本。但是，很多网站项目是”持续发布”，代码一有变动，就部署一次。这时，master分支和develop分支的差别不大，没必要维护两个长期分支。
参考资料
若有收获，就点个赞吧
0 人点赞
