我怀疑我知道这个问题的答案，但我希望我错了。
我们在一个分支上做了很多工作，我打算将它与 master 合并为一个 rebase，以便在所有部分都到位后保留我们所有的历史记录。我提出了一个拉取请求，其中一位审阅者批准了它并做了一个“Squash and Merge”。无论如何，合并还为时过早，我们恢复了 master 上的更改，但这使新目录在 master 上具有历史记录。现在没有“Rebase and Merge”选项（github 已灰显）。我试图将分支变基到本地主控，但它失败了，错误指向删除先前合并文件的提交。
我已经用尽了我的 git-fu。有没有办法摆脱对 master 的手术和强制推送，考虑到拥有 repo 的人数，这不太可能实现？
【问题讨论】：
标签： git github git-merge git-rebase
有没有办法摆脱大师的手术不足
在某种意义上，不。从所谓的 Squash and Merge（我说所谓的 Squash and Merge 实际上不是任何一种合并）的那一刻起，就从来没有。你所做的，恢复，继续前进；它甚至添加了 more 次提交。 “撤消”实际历史的唯一方法是重置。这就是你倒退的方式。对已推送的材料进行重置的唯一方法是强制推送。
但是，我也不会说一切都丢失了。当然，您的历史是一团糟，但那又如何？在这一点上，这只是历史上的一个小故障；总有一天它会消失在时间的流沙中。 现在重要的是master——意思是，在任何人进行任何形式的合并之前，master 上的最后一次提交——应该处于正确的状态（我的意思是，正确的状态你所有的文件）。因此，只需安排该状态，无论它可能是什么，并将其直接提交到 master，然后继续。
我还想说我不同意这个问题的前提。你说：
我打算将这个 [branch] 与 master 合并为一个 rebase，以便在所有部分到位后保留我们所有的历史记录
错了。 “合并为变基”不会“保留历史记录”。它撒谎关于历史。保留分支历史的方法是 merge 分支，简单明了。变基不是合并；壁球不是合并； merge 是一个合并。合并是好。它们是保存发生的事情的最干净的方式，同时使未来有可能顺利进展。 （举个例子，如果您进行了真正的合并，那么如果您发现合并为时过早，您可以继续在分支上工作，修复它，然后再次合并它。事实上，正如您所发现的那样, 没那么简单。）
【讨论】：
如果我理解正确，你有以下情况：
squash&merge feature in master
| revert the squash&merge commit
v v
*--*--*--*--*--M--*--*--R--*--*--* <- master
\
*--*--*--s--*--* <- feature
^
the state of the `feature` branch when it was squash&merged
您可以尝试在R 之上重新设置feature -- R 中的文件状态可能与feature 开始修改它们时的文件状态足够接近，这可能在没有太多的冲突。这很大程度上取决于master（上图中的*）上的other 提交带来的修改。
如果这不起作用（冲突太多），这里还有另一种将历史片段重新拼接在一起的可能性：
# 1. starting from commit R :
git checkout -b wip R
# 2. re-revert R :
git revert R
# 3. replay commits s..feature on top of this new commit :
git rebase --onto wip s feature
这将丢弃feature 历史的开始（直到提交s）。
【讨论】：