推送后可以重写 Github 拉取请求吗？答案

【问题标题】：Can a Github pull request be rewritten after push?推送后可以重写 Github 拉取请求吗？
【发布时间】：2021-08-29 07:44:15
【问题描述】：

我向 Github 项目发送了一个简单的拉取请求。一位维护者提出了一种不同的方法。如何使用新方法调整我的拉取请求？

我知道向已经存在的拉取请求添加提交是正常的，但在这里我基本上会撤回整个第一次提交。标准方法是什么？

【问题讨论】：

你可以添加新的提交，没关系。如果你愿意，你可以在 PR 准备好时将它们压缩（stackoverflow.com/questions/5189560/…）成单个提交
感谢@JonhyBeebop！即使分支的拉取请求已经在上游打开，我可以压缩分支吗？
@JonhyBeebop 我正在阅读链接的问题，并且高度评价的评论警告“注意只压缩本地提交。永远不要触摸推送的提交！”
关闭公关重新开始？
@Anna 是的，你可以压缩推送的提交。添加带有-f（强制）标志的推送新（压缩提交）。是的，这有点吓人，因为您可以删除不想删除的内容。但我仍然认为你应该只添加新的提交，不要考虑以前的。在开发过程中，解决方案的整个概念发生变化是可以的

【解决方案1】：

你基本上有三个选择。

关闭 PR 并重新开始。在新分支的开始点（或上游主分支的当前末端）开始一个具有不同名称的新分支。
保留当前 PR 并向其推送新的提交。在这种情况下，我建议从撤消整个初始尝试的单个还原提交开始，如How to revert multiple git commits? 的一些答案中所述
按照某些 cmets 中的建议，通过变基 /squash 来保留当前 PR 并重写历史记录以隐藏您的第一次尝试。我强烈反对这个想法。不要重写推送的提交。

【讨论】：

虽然“不要重写推送的提交”一般来说是一个好建议，但我认为只为发出拉取请求而存在的分支是一个例外，因为替代方案更糟。关闭拉取请求并开始新的请求会破坏对该功能的讨论。当合并拉取请求时，将被拒绝的方法保留在历史记录中会给主分支的历史记录增加不必要的混乱。

【解决方案2】：

如果您想替换现有的提交，您可以强制推送到与拉取请求相关的分支。

【讨论】：