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

Question

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

我现在的问题是，我的功能已被拆分为 Epic，目的是制定渐进式部署计划。每个故事都应该是一个特色。绝大多数故事的设计使得它们之间没有任何依赖关系，能够单独实现它们。但是，需要注意的是，它们都依赖于一个共同的故事。

目前，通用故事（功能）已完成，但尚未通过测试/QA 部门，因此我无法将其合并回开发分支。但我想开始创作史诗中的另一个故事。

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

Answer 1

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

但是，如果您想要更清晰的历史记录，您也可以拥有它。一旦依赖的特性分支被合并到develop，然后检查你的新特性分支并执行：

git rebase develop

在 rebase 期间，Git 会看到来自依赖分支的提交已经合并到 develop，因此功能分支中不再需要它们。因此，您的功能分支现在将只包含特定于该功能的新提交。

如果你已经将它推送到服务器，你还必须这样做：

git push --force-with-lease

现在你的特性分支就像在依赖特性被合并后直接从develop 出来一样。