这是我的场景：
我的项目遵循主题分支模式。
我创建了一个分支来修复一些问题，我们称这个分支为problem_fixes。我进行了更改，并提交了一个拉取请求。
我需要开始开发一个新功能，所以我创建了第二个名为 my_feature 的分支并提交了一堆更改。
在某些时候，我意识到 my_feature 依赖于尚未被接受和合并的问题修复（my_feature 分支依赖于第一个分支的一些修复，没有它们我无法取得进展）。
没有纠缠我的项目导致更快地接受和合并我的第一个分支，这里遵循的最佳流程是什么？
我想知道是否需要基于 problem_fixes（而不是 master）启动一个新的第三个分支并合并我对 my_feature 的提交？或者，如果我只是将问题修复合并到 my_feature 并继续工作，是否可以 - 假设问题修复首先合并到主库，当 my_feature 被合并时，理论上应该没问题（？）
从第一个分支创建您的主题分支。一旦第一个合并到 master 中，您就可以在此基础上进行 rebase，并且假设没有进行太多更改，这应该不是问题。
如果第一个分支的提交未更改，您的新分支将整齐地堆叠在其之上，并且如果提交更改（压扁、编辑或其他），您始终可以对第二个分支进行交互式变基并将其编辑为合并第一个分支后看起来不错。
是的，我认为你在正确的轨道上。我会做的是创建一个新的my_feature分支，也许工作一点。当我意识到这my_feature取决于时problem_fixes，合并该分支。如果你知道你需要它，这可能会立即发生。然后，当my_feature合并到 master 中时，您将已经拥有所需的更改。
请注意，只要您有一个健壮的代码审查程序，那么如果您尝试在之前合并my_feature到 master 中problem_fixes，那么您会在那个时候注意到。
在我开始工作的情况下，我master意识到我需要来自另一个无法合并的分支的一些更改，因为它仍然有一些破坏性的东西（但我需要的东西是完整的）我会做什么这种情况可能是
将他们的分支合并到我的分支中
完成我的功能
等待其他开发人员完成他的功能
它们融合成master
我挑选我的提交期望合并提交master
你们怎么看，可能是摆脱一个特别痛苦的情况的一种方法，尽管它涉及到挑选樱桃，大多数人认为这是一种痛苦，就像变基一样。