我怀疑我知道答案，但是想检查一下，因为我希望我错了。
我们在分支机构上做了很多工作，我打算将其与master合并为基础，以便一旦所有内容都准备就绪，便可以保留我们的所有历史记录。我提出了要求请求，其中一位审阅者批准了该请求，并进行了“压缩合并”。无论如何，合并还为时过早，我们还原了master上的更改，但是新目录中保留了master上的历史记录。现在没有“重新合并”的选项（github已变灰）。我试图将分支重新设置为本地母版，但是它失败，并出现错误，指出删除了先前合并文件的提交。
我已经筋疲力尽了。在大师和强行推动下，这种短时间手术是否有办法解决，鉴于拥有回购协议的人数，这不太可能实现？
答案 0 :(得分：2)
在师父的这种短暂手术中是否有出路
从某种意义上说，不是。从所谓的Squash and Merge开始，就从来没有（我之所以这么说是因为Squash and Merge实际上并不是任何形式的合并）。恢复后，您所做的前进；它甚至添加了 more 个提交。 “撤消”实际历史记录的唯一方法是重置。那就是你往后走的方式。对已被推入的材料进行重置的唯一方法是强制推入。
但是，我也不会说所有的一切都丢失了。当然，您的历史很烂，但是那又如何呢？在这一点上，这只是历史上的一个小故障。有一天，它会在时光流逝中迷失。 now 的重要之处在于master（也就是说，在master上对任何人进行任何类型的合并之前的最后一次提交）应该处于正确的状态（我的意思是，您所有文件的正确状态）。因此，只需安排该状态，无论其状态如何，然后将其提交到master上，然后继续即可。
我也想说我不同意这个问题的前提。你说：
我原本打算将此[分支]与master合并，以作为基础，以便一旦所有内容都就位后就可以保留我们的所有历史
错了。 “合并为基础”不会“保留历史”。关于历史的谎言。保留分支历史的方法是合并简单明了的分支。变基不是合并；壁球不是合并； merge 是一个合并。合并是好。它们是保存发生的事情的最干净的方法，同时使未来有可能整齐地发展。 （仅举一个例子，如果您进行了真正的合并，那么，如果您发现合并为时过早，则可以继续处理分支，对其进行修复，然后再次对其进行合并。 ，这不是那么简单。）
答案 1 :(得分：2)
如果我理解正确，则您遇到以下情况：
value您可以尝试在 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
之上重新建立feature的基础-R中文件的状态可能与R开始修改时的文件状态足够接近他们，而这可能会在没有太多冲突的情况下起作用。这很大程度上取决于 other 对feature所做的修改（上图中的master）。
如果那样行不通（冲突太多），这是另一种重新组合历史记录的可能性：
*这将丢弃# 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）。