如何将Gitflow与功能分支之间的依赖关系一起使用？

我正在使用GitFlow，其功能分支映射到用户情景。本质上，每个功能分支代表一个用户故事。当故事被完全实现和测试时，它被认为已经完成，并且特性已经完成（合并回开发分支）

我现在的问题是，我的特性已经被分解成一个Epic，目的是有一个渐进的部署计划。每个故事都应该是一个特色。绝大多数的故事都是这样设计的，它们彼此之间没有任何依赖关系，能够单独实现它们。然而，有一个警告是，它们都依赖于一个共同的故事

目前，通用故事（特性）已经完成，但还没有通过测试/质量保证部门，所以我还不能将其合并回开发分支。但我想开始史诗中的另一个故事

---

此时的“正确”流程是什么？我是否应该从现有功能分支的头部创建一个功能分支？它不遵循典型的GitFlow流程，因此我想知道其他人是如何解决这种情况的。

是的，您应该从现有功能分支的尖端创建一个功能分支。与大多数流程一样，Git流更多的是一组指导原则，而不是实际规则

然而，如果你想要一个更干净的历史，你也可以拥有它。相关要素分支合并到

开发

后，请检查新要素分支并执行以下操作：

git rebase develop

在rebase期间，Git将看到来自从属分支的提交已经合并到

develope

，因此功能分支不再需要它们。因此，您的功能分支现在只包含特定于该功能的新提交

如果已将其推送到服务器，还必须执行以下操作：

git push --force-with-lease

---

现在，就好像您的功能分支在相关功能被合并后直接从

develope

中走出来一样。

。很高兴知道我的心态是正确的。感谢您结束了关于如何完成它的循环。