放弃Gitflow Workflow的原因——Gitflow Workflow（六）

最新推荐文章于 2024-06-05 16:46:43 发布

u010020404

最新推荐文章于 2024-06-05 16:46:43 发布

阅读量336

点赞数

分类专栏： SDK项目开发&管理文章标签： git devops

本文链接：https://blog.csdn.net/u010020404/article/details/125132937

版权

SDK项目开发&管理专栏收录该内容

16 篇文章 1 订阅

订阅专栏

Gitflow的简单回顾总结

尽管Gitflow有着诸多优点：

master分支的任何tag都是一个可发布版本
在发布候选分支上进行测试，不影响develop分支下一个版本的开发
可以方便的将发布候选分支的bugfix和hotfix分支的hotfix合并入develop和master分支

但是它也存在着几个缺点：

合并周期太长
不支持多版本并行开发（或者说支持的很糟糕，很容易合并错误）
适合可预测的版本发布，对不可预测的版本发布支持不友好

Gitflow合并周期太长

合并周期长的缺点就是容易发生合并冲突，或者说发生合并冲突后解决问题困难。

我们在使用其它branching model的时候也需要注意这一点，要缩小提交的粒度，增加提交的频率。尤其是多人协作开发同一部分功能的时候。这样及时有合并冲突，我们也能及时发现，修复的成本也最低

Gitflow合并周期长的几个节点：

feature branch合并入develop分支（这个可以人为地缩小feature branch来减小合并冲突的scale）
release candidate分支合并入develop分支和master分支（此两处合并周期最长，合并冲突风险大）
hotfix分支比较短小，合并周期一般小一些

release candidate分支在几轮rc测试，bugfix后合并入develop分支，时间较长，发生冲突概率大，解决冲突的成本大。

release candidate分支在合并入develop分支后还需要合并入master分支，这个时间算上在develop分支上开发feature的时间就更长了（虽然我们不直接往master分支上提交feature，可以认为合并入master分支发生合并冲突的概率和成本跟合并入develop分支一样）。