首先让我简单介绍一下我们的设置。我们有一个“主”GitHub仓库，我们只能通过拉动请求提供。我们在GitHub上也有一个私有分支，所有工作都在这里发生，我们实际创建了pull请求。最后，有一个私有分叉的本地克隆。
手头的任务是重写大量的提交消息，显然git filter-branch是这里的首选工具。
我在我的本地克隆仓库中创建了一个临时分支并成功完成了所有过滤 - 这显然创建了一个“替代历史记录”，其中所有提交都受到过滤器的影响。然后，如https://stackoverflow.com/a/15256575中所述，我已将本地主人重新定位到临时分支上。
现在的问题是 - 最安全的方法是什么：
git push --force-with-lease可能是最佳选择，但我从未尝试过与filter-branch一起尝试，所以我不确定这是不是一个好主意。谢谢！
答案 0 :(得分：1)
关于制作临时分支和重新定位的答案适用于其他方面。如果你在主人之上重新设置过滤后的分支（主人），我不知道你的回购现在处于什么状态。
您希望通过将主计算机重置回原来的位置来撤消该操作。如果您未在master上进行任何其他提交，则可以使用origin/master重置回git reset --hard origin/master。然后在master上进行过滤。
通常情况下，您不会使用拉动请求进行此类手术。 PR用于表现良好的功能分支，而不是重写历史记录（尽管您可以安全地重写已作为PR提交的分支）。相反，您可以使用过滤器，检查它是否正确，git push --force，并让每个人都知道master已被重新定位。我不认为为这类事情设置拉取请求。
这就是原因。让我们说过滤器所做的第一个更改是在C.结果基本上是一个新的分支。
A - B - C - D - E - F - G - H [origin/master]
\
C1 - D1 - E1 - F1 - G1- H1 [master]
因为提交是由前一次提交定义的，所以当你重写一次提交时，Git必须重写它的所有子提交。即使它们包含相同的内容，它们也会是具有不同提交ID的不同提交。
如果您将此作为拉取请求提交......我不确定Github会做什么。它要么把它当作一个分支来对待并且弄得一团糟，要么Github有一些关于变基的魔力。试试吧？将它作为PR发送，看看Github用它做什么。如果它不起作用，请删除PR并手动执行。
另一个，AFAIK，一个不可避免的问题是，一旦你的过滤被推上游，每个人都会受到影响。 每个人必须git pull --force，每个人都必须在新主人的基础上重新分支他们的分支。
因此，考虑过滤是否值得改变一些提交消息。