这是我的情况：
我的项目遵循主题分支模式。
我创建了一个分支来修复一些问题，让我们称之为problem_fixes。我进行了更改，并提交了一个拉取请求。
我需要开始开发一个新功能，所以我创建了第二个分支，称为my_feature，并提交了一堆更改。
在某个时刻，我意识到my_feature依赖于尚未被接受和合并的problem_fixes（my_feature分支依赖于第一个分支中的一些修复，我不能没有它们继续进展）。
除了强迫我的项目负责人更快地接受和合并我的第一个分支外，这里最好的流程是什么？
我在想，我是否需要基于problem_fixes（而不是master）创建一个新的第三个分支，并合并我的提交到my_feature？还是如果我只是将problem_fixes合并到my_feature并继续工作，假设problem_fixes首先合并到master，则理论上应该没问题（？）
从第一个分支创建你的主题分支。一旦第一个分支合并到主分支，你就可以在其之上进行变基操作，假设没有太多的更改，这应该不是问题。
如果第一个分支的提交没有更改，你的新分支将整洁地堆叠在其之上。如果第一个分支的提交被更改了（压缩、编辑或其他），在第一个分支已被合并后，你可以对第二个分支进行交互式变基操作，并进行编辑，使其看起来更好。
是的，我认为你走在了正确的道路上。我的建议是创建一个新的my_feature分支，并进行一些工作。当我意识到my_feature依赖于problem_fixes时，将该分支合并进来。如果你知道你需要它，这可能会立即发生。然后，当my_feature合并到主分支时，你已经拥有所需的更改。
请注意，只要你有一个强大的代码审查流程，那么如果你尝试在将problem_fixes合并到主分支之前将my_feature合并到主分支，那么你会在那时注意到这个问题。
如果我从master开始工作，后来意识到需要一些其他分支的更改，但由于它仍然存在一些破坏性内容（但我需要的内容是完整的），无法合并，那么我可能会做以下几步：
将他们的分支合并到我的分支中
完成我的特性
等待另一个开发人员完成其特性
他们将合并到master
我选择我提交的内容（除了合并提交）合并到master中
你们觉得这个方法如何？尽管涉及到使用像变基一样繁琐的cherry-picking操作，但是这可能是避免特别痛苦情况的一种出路。
