我将 GitFlow 与映射到用户故事的功能分支一起使用。本质上，每个功能分支都代表一个用户故事。当故事完全实现和测试时，它被认为已经完成，并且功能完成（合并回开发分支）。
我现在的问题是我的功能已被拆分为 Epic，目的是制定渐进式部署计划。每个故事都应该是一个特色。绝大多数故事都经过设计，因此它们之间实际上没有任何依赖关系，以便能够单独实现它们。然而，需要注意的是，它们都依赖于一个共同的故事。
目前，common story（特性）已经完成，但是还没有通过测试/QA部门，所以我还不能把它合并回develop分支。但我想开始创作史诗中的另一个故事。
此时的“正确”过程是什么？我应该从现有功能分支的 HEAD 创建一个功能分支吗？它不遵循典型的 GitFlow 流程，所以我想知道其他人是如何解决这种情况的。
是的，您应该从现有功能分支的顶端创建一个功能分支。与大多数流程一样，Git Flow 与其说是实际规则，不如说是一套指导方针。
但是，如果您想要更清晰的历史记录，您也可以拥有它。一旦从属功能分支合并到develop，然后检查您的新功能分支并执行：
git rebase develop
在 rebase 期间，Git 会看到来自依赖分支的提交已经合并到develop，因此特性分支中不再需要它们。因此，您的功能分支现在将只包含特定于该功能的新提交。
如果您已将其推送到服务器，则还必须执行以下操作：
git push --force-with-lease
现在，就好像您的功能分支develop在从属功能合并后直接关闭一样。