gitflow中的Develop分支没用吗?

问题描述 投票:3回答:3

每当我在团队中寻找使用git的正确方法时,我们总是指git-flow。

我们从一开始就将此计划用作圣经。

enter image description here

经过时间,我们最终发现将master保持为带有标记提交的稳定分支是浪费时间。

您为什么标记您的稳定提交,然后按PUSH以掌握您已标记的相同版本。标签存在,您可以随时返回此提交。我为什么要麻烦保留该分支仅包含标签?

这是我们使用的流程,它就像一种魅力。

Master:实际上是我们的开发部门发行版:我们创建发行版分支来进行最后的发行测试用例,然后根据需要添加修复程序。功能:我们从Master分支创建功能,然后将拉取请求发送给master。

实际上是与gitflow相同的名称,没有包含稳定的分支。

另一个优点是,MASTER是DEVELOP分支。因此,当新的队友进入该项目时,他可以从克隆该项目开始,而他的主人已经与实际开发保持同步。

在图片中:

enter image description here

我的问题是,如果您只能用相同的结果管理4个分支,为什么还要使用5个分支的原始git-flow?

git git-flow git-workflow
3个回答
6
投票

我认为您的工作流程有一个大问题:过度使用开发/主分支。

您基本上是说,不需要区分母版和开发,因为将标签保留在开发上就足够了。乍一看似乎很合理,但是您修改过的图像隐藏了分支的需要:修补程序。

假设您的代码版本稳定,并且已经完成了发布阶段。现在您相信一切就绪,并在master / develop上创建标签。一段时间后,客户使您注意到您有一个错误,并且您尚未准备好发布新版本。你是做什么?

您唯一的选择是从master / develop分支。因此,功能,发行版和修补程序将来自主机。这种方法的另一个缺点是,一旦在修补程序分支上解决了一个错误,您便会将其合并到development / master中,但是您不能在该提交上放置标签,因为develop / master分支可能同时移动了,并且它将有更多的(未测试)客户不应该拥有的功能。我认为这太过分了,在某些时候将很难理解提交历史。但是,正如我刚开始所说的那样,这值得商bat。

您的工作流程似乎混合了基于git-flow和主干(或主版本)的开发,但是大多数都从它们身上取了缺点。


5
投票

结果是不同的:在简单的git-flow master中,它始终是稳定的-这是您团队之外的可交付人员可以依靠的。您的master是gitflow-peak中developmaster的混合物。合并重要功能后,无论结果是否真的稳定并准备好发布或需要更多错误修正,都无法下注。

就是说:Git工作流不是上帝赋予的。 Git-flow受到了很多批评。如果您的团队和依赖您代码的团队感到满意,那么请以最小的开销进行工作流。

最后一点:

这是我们使用的Git-Flow,它的工作原理就像是一种魅力。

请执行NOT称您的工作流为“ git-flow”。选择一个明显不同的名称。稀释一个好的搜索词对任何人都没有帮助。


0
投票

一年后,

我终于明白了git流中两个分开的分支的必要性。

您需要Git-flow的唯一原因是当您拥有一个CI / CD,并且可以通过对master分支的任何提交自动部署到生产中。

去年,当我问这个问题时,我们没有将其自动部署到生产环境中。因此,我们可能会认为在没有Develop / Master的情况下使用的方法是ok,并且因为我们不必再管理一个分支,因此为我们节省了一些时间。

由于我们使用管道系统(将任何提交到Master分支后都发布到生产中,因此它为该分支提供了目标!是的,master分支包含已标记的版本,但是还附带了用于自动部署到生产环境的脚本!

© www.soinside.com 2019 - 2024. All rights reserved.