开发阶段的Git-flow

Question

在sprint开发期间，你是如何处理git流的？

我发现在开发期间，一些sprint任务是相互依赖的，所以不可能从master分支分支，因为它太早了，而且需要开发分支的功能才能继续在sprint上工作。

目前，我在sprint期间从开发分支，并对我正在从开发分支工作的分支进行重新基址。我发现使用这种方式，master仍然是稳定的，我们避免在分支之间进行大量的合并，以使项目达到继续开发所需的状态。

我认为这一部分到处都被遗漏了，我找不到一种有文档记录的方法来避免所有这些麻烦。

在开发期间，热修复不是master的分支，因为我们修复的功能可能是由功能冲突引起的问题，所以我们从开发中创建热修复。一旦开发合并了所有的sprint任务，并且我们修复了所有的热修复，我们就将开发合并到master中。我们不使用发布分支，因为我们没有预生产服务器，所以没有意义。

但我觉得在开发期间将开发作为一种主分支，并在开发阶段之后改变其含义是相当令人困惑的。让我更好地解释一下。

在开发阶段之后，开发分支将保留基于当前主分支的功能。而在开发阶段，新功能将基于开发分支。

你能给我带来一些关于如何避免这种情况的启发吗？

谢谢。

Answer 1

我将说一些你显然会认为是错误的东西，所以这里有一个可供参考的资源：https://datasift.github.io/gitflow/IntroducingGitFlow.html

在正常的gitflow中，功能分支是从开发创建的；所以你不能从master创建功能分支的观点，所以你通过分支表单开发来“解决这个问题”只是意味着你遵循了gitflow。我不知道从master创建功能分支的想法是从哪里来的…

你提到了从开发中重建基础...去哪里？师父吗？什么时候?在gitflow master中，只包含最终释放提交。无论如何，我不建议对推送的任何内容(特别是作为日常工作流程的一部分)进行重新设置基础。

如果您的修补程序是分支表单开发，那么您不能将它们合并到master中，直到您准备好将开发中的所有内容也合并到master中。(您可以精心挑选它们，但这样代码就会处于未经测试的状态。)如果您的补丁必须等待常规版本才能进入主版本(从而进入生产环境)，那么它就不是热补丁。

如果你要改变我到目前为止提到的实践以符合gitflow，我想你会开始看到发布分支的价值。我建议你忘记你所知道的关于gitflow的知识，重新学习它。或者，您可以完全放弃使用gitflow的想法，并使用自己的分支模式，但如果是这样的话，您就忽略了导致gitflow作为解决问题的解决方案的积累的知识。