Git：使用nvie的gitflow概念和暂存环境

Question

我们使用nvie's gitflow作为我们的git分支策略的模式，并且或多或少相当接近它。

主要区别在于临时环境，我必须将其整合到现有策略中。

起初相当直接。 暂存只不过是一个我们可以与新版本分支合并的简单分支。将其推送到origin / stageserver并执行我们在暂存期间要执行的操作。到现在为止还挺好。

但是，让我们说我们在分期中发现我们想要纠正的东西（小错误修正，甚至可能是新集成功能中的错误？）。对我来说还不清楚，处理这种情况的好策略是什么。

我目前的想法围绕以下策略：

• 从origin / staging创建分支staging_fix
• 更正错误
• 重新运行暂存过程+测试
• 将staging_fix分支与发布分支合并
• 从原点拉出释放分支
• 根据nvie继续使用gitflow，因此准备发布分支进行生产等......

你认为这是个好主意吗？ 这会导致对分段分支的直接更改，这对我来说似乎是一个快捷方式，因为我必须直接修改暂存环境 - 你不会对你的生产环境做些什么，我希望升级类似于尽可能生产。

或者，可以直接更正释放分支并一次又一次地将其推送到暂存，直到所有错误都得到解决。至少现在我们有一条改变的单行道。

您更喜欢哪种方式？你会在这里建议一个不同的策略吗？

Answer 1

这似乎是一个很好的策略，因为：

• 它在一个仓库（在登台服务器上）隔离登台（及其相关的合并工作流程）
• 它允许从该登台服务器提取您需要重新集成的内容并将其合并回您自己的dev repo。

如果在登台仓库中完成的修复（与在repo中完成的修复和推送到分段相反）需要花费太多时间，并且合并变得过于复杂（因为代码修改中存在很大差距），这只会变得很麻烦）。

Answer 2

如果你遵循git flow模式并且在我的理解中，这就是我们应该如何进行的： - 处理您的功能，完成后，将其合并回您的开发分支git flow finish feature MyFeature

• 如果要测试功能，请创建发布分支 git flow release start YourRelease，它将包含已完成的所有功能并合并回您的分支开发。

• 在您的暂存环境中部署您的发布分支，修复发布分支中的错误，重新部署分支，修复错误等等......直到您对发布分支感到满意为止。

• 当发布分支准备部署git flow finish release YourRelease时，会将重新合并到主服务器和暂存中。

• 将master分支部署到您的生产环境中。

我可以看到的问题是，如果需要删除合并到分段中的功能（太多错误，功能计划中的更改等等），您就会遇到一个您不再需要的功能开发和发布分支，在撤消此功能之前，您无法继续使用其他功能/发布...