堆叠式PR重新设定/修改工作流程

Question

我有以下工作流程来在git中执行堆叠的拉取请求（我喜欢做很多小的依赖的PR）：

* Start your feature_b from feature_a, i.e.:
git checkout feature_a
git checkout -b feature_b
* Whenever feature_a changes while it is waiting to get merged into master, you rebase feature_b on it:
... commit something onto feature_a ...
git checkout feature_b
git rebase feature_a
* Finally, as soon as feature_a has been merged into master, you simply get the new master and rebase feature_a onto it a last time:
git checkout master
git pull origin master
git checkout feature_b
git rebase --onto master feature_a feature_b

这适用于一些依赖项，但是在达到feature_c或d之后，如果我想在feature_a分支中进行某些更改，我最终不得不重新设置基础。理想情况下，当我编辑给定的PR时，我希望运行“修改此提交并将所有相关的提交重新建立基础”命令，并且当我合并一个或多个最初的PR，其余的仍在审核中。

当我使用水银笔时，我使用了hg amend --rebase（https://bitbucket.org/facebook/hg-experimental）为我做这件事。好奇是否有git或我可以编写以实现相同功能的脚本？

rerere看起来像是在这里使用的好工具，再加上其他一些东西，可以使依赖的变基过程本身自动化。

Answer 1

我从来没有找到一个好的技术解决方案。深入了解层可能表明您的审核和合并过程太慢。还是您的分支机构太好了。还是太相互依赖。或所有这些。

审核过程太慢

很显然，我们大家都希望我们的PR尽快复审并合并。有些地方比其他地方做得更快。 CI流程可能很慢。开发人员可能没有优先考虑审核。 PR可能太复杂了。我不能说如何在您的项目中解决此问题，只是会加剧其他问题。

分支太精细且相互依赖

大概是在堆叠分支，因为特征A需要特征B，特征B需要特征C，依此类推。如果您习惯性地进行此操作，那么要问的是为什么您的工作如此习惯性地相互依赖？为什么不能单独开发功能A，B和C？分支依赖有时是食物。

这可能是因为代码之间的相互依赖性太多，需要对其进行重构。这些任务可能过于相互依赖，需要重新考虑。分支可能太大，并且包含太多必要的更改。再说一次，我不能为您的商店说​​什么，但我建议您考虑一下。

您现在需要合并每个功能吗？

除非您现在绝对需要合并功能A，否则它等不及要完成相关功能B和C，也许只是将它们作为一个分支来进行即可。如果您在工作时希望获得反馈，则可以推动分支机构并要求反馈到目前为止所做的事情。