GitFlow 工作模式（详解）

今天再学项目的过程中遇到使用gitflow模式管理代码，因此进行学习并且发布关于gitflow的一些思考

Git与GitFlow模式

我们在写代码的时候通常会进行网上保存，无论是github还是gittee，都是一种基于git去保存代码的形式，这样保存代码会十分的整洁并且丢失后还容易找回，但是，你会发现如下问题：

版本管理不够清晰如果没有良好的规范，master 分支可能包含未完成或不稳定的代码。

不适合多版本维护缺乏 release 和 hotfix 分支，难以同时维护多个版本或快速修复生产问题。

并行开发支持较弱虽然支持功能分支，但没有明确的集成分支（如 develop），可能导致集成混乱。

但是gitflow模式通过多种严格的代码流程处理掉了这些问题，具有优势，我们将通过此篇文章讲解gitflow的模式是如何处理这些问题的

当然劣势也有，请拉到文章底部查看

GitFlow工作模式

master分支

发布上线时，基于master打tag，基于tag进行发布，不允许在该分支上开发，始终保持该分支的稳定。

develop分支

开发阶段使用的分支，提交到该分支代码都是相对稳定的，不能直接基于此分支开发，如果开发新的功能，需要基于此分支创建新的分支进行开发功能，待功能开发、测试通过后合并到develop分支。

Feature分支

当你需要去开发新的功能的时候，需要创建feature分支，功能开发完后合并到Develop分支，禁止未开发完成的代码合并到Develop分支。

Release分支

当你的feature分支合并到develop分支之后，此时需要基于Develop分支创建Release分支，在Release分支中不再添加新的功能，只是做bug的修复，等测试完成bug全部修复之后，需要将Release分支合并到Master分支和Develop分支，并且基于Master打出版本的tag。

hotfix分支

如果发布到生成环境的版本出现bug，比如：生产环境的v1.0版本出现bug需要尽快修复，此时就需要基于master创建hotfix分支，并且基于hotfix分支修复bug，待bug修复完成后需要将代码合并到master和develop分支。

基于以上流程，你就会能够处理git流程的一些缺陷

gitFlow的优势

适合有明确发布周期的项目 GitFlow 对版本控制非常严格，适合需要定期发布、维护多个版本（如企业软件、移动应用）的项目。

版本管理清晰 master 分支始终代表可发布的稳定版本，develop 分支代表即将发布的版本，功能分支隔离开发，便于管理。

并行开发支持好多个功能可以同时在不同的功能分支上开发，互不干扰，提高团队协作效率。

热修复机制完善紧急问题可以通过热修复分支快速修复并发布，同时不影响开发主线。

劣势

流程复杂，学习成本高 GitFlow 分支模型较为复杂，对新手不友好，团队需要花时间学习和适应。

不适合持续集成/持续交付（CI/CD） GitFlow 的发布周期较长，分支较多，与现代 CI/CD 的快速迭代、频繁发布的理念不太契合。

合并冲突风险高由于分支多，合并频繁，容易产生合并冲突，尤其是在大型项目中。

维护成本高需要严格遵循流程，否则容易导致分支混乱，增加维护难度。

Git与GitFlow模式