开发阶段的Git流程

Question

如何在冲刺开发期间处理Git流程？

我发现在开发过程中，一些sprint任务是相互依赖的，所以不可能从master进行分支，因为它在历史中太过分了，并且需要开发分支继续在sprint上工作的功能。

目前，我在sprint中从开发分支并重新设计了我正在开发的分支。我发现使用这种方式，master仍然总是稳定，我们避免在分支之间进行大量合并，以使项目进入继续开发所需的状态。

我觉得这部分是无处不在错过了，我无法找到一个文件的方式来避免这一切的麻烦。

发育过程中，修补程序无法从主分支，因为我们修复功能可能是由功能引起的冲突的问题，所以我们创建从开发修补程序。一旦开发将所有sprint任务合并并修复所有修补程序，我们会将开发合并到master中。我们没有使用发布分支，因为我们没有预生产服务器，所以没有必要拥有它。

但我觉得有发展作为发展过程中的一种主分支并改变它们的含义之后的发展阶段是相当混乱。让我更好地解释它...

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

您能否告诉我如何避免这种情况？

谢谢。

Answer 1

我会说一些事情，你显然会认为是错误的，所以这里仅供参考来源：https://datasift.github.io/gitflow/IntroducingGitFlow.html

在正常gitflow，从发展创造功能分支;所以你指出你不能从master创建功能分支，所以你通过分支表单开发来“解决这个问题”意味着你正在关注gitflow。我不知道在哪里的理念，以创建主会来从功能分支...

你提到垫底从发展......在哪里？掌握？什么时候？在gitflow master中只包含最终发布提交。无论如何，重新设定推送的内容（特别是作为日常工作流程的一部分）并不是我推荐的。

如果您的修补程序分支形式的发展，那么你不能将它们合并到主直到你准备好了一切高达发展这一点也被合并到主。 （你可以挑选它们，但是你有一个未经测试的代码状态。）如果你的修补程序必须等待定期发布去掌握（并因此到生产），那么它不是修补程序。

如果你要改变我说过的做法，到目前为止，以符合gitflow，我想你会开始看到的版本分支的价值。我建议你忘记你对gitflow的了解并重新学习它。或者，你可以放弃你使用gitflow的想法，并推出你自己的分支模式，但如果是这样的话，你会忽略积累的知识，导致gitflow作为你遇到的问题的解决方案。