Git还原合并提交，丢失了一些文件

因此，我错误地合并了

发布版上的
功能
分支

，并按下了按钮。 然后用合并提交的反向提交将其还原回来，一切都进行得很顺利

当尝试将

发行版

合并到

主版

时出现问题，注意到一些丢失的文件和奇怪的更改。当损坏的合并被实际推到我的

主分支上时，问题变得更加可怕

回顾revert merge commit
（W1）
，我看到所有缺失的文件都在反向提交中删除了文件

请记住，
功能
分支无论如何都会在
主程序
上进行合并，我考虑在反向提交
主程序
上使用rebase-I，就像合并是在没有反向提交的情况下进行的一样

你认为有更好的解决办法吗

谢谢大家！：）

编辑
首先，感谢您的关注和回复！为了更好地解释情况，我在图片上添加了一些内容。

实际上，我们不再关心图片中的
发布
分支，它只影响少数文件，并且可以出现在
主版
上，没有任何重大问题。在创建
发行版
和
功能
之间，在
主文件
中进行的文件添加和修改

在发布合并
（M2）
删除
（W1）
之后，我正在重新设置主分支的基础。我知道我们正在失去一些发布历史，但我认为“保存”实际发布的代码是更好的解决方案，如果有必要，我们可以从中开始回购。
大约有1000个承诺要重新设定基础，一些冲突正在蔓延。我正在用每个文件的最新正确版本更正每个明显的冲突

编辑2
最后，我们重新设置了
主分支的基础，然后在分支顶部应用差异，如“假基础”，这样更改是可见和可更改的。
更新：

根据你最新的问题，我明白为什么会发生文件删除。对我来说，这似乎是一个不寻常的环境组合。最有趣的一点是，恢复合并是一个比我乍一看更危险的操作。撤消合并（通过重置以在推送之前将其从历史记录中清除）是典型的过程，如果在推送之前发现问题，则可以避免此类问题。但这在现在并没有多大帮助

尽管有澄清，我仍然建议您不要修改历史记录，我的所有建议都包含在我的原始答案中。请记住，如果您以编辑来自
发布
的提交的方式重新设置
主控
，
发布
仍将有原始提交，并且您将有一个奇怪的、分裂的历史，在某些合并操作上容易发生冲突（因为重复提交执行相同的操作）

如果您想将M1中的所有更改放回历史记录中，可以通过还原W1来减少麻烦。你仍然可能会遇到一些冲突，但这是一个简单得多的过程开始；不会造成上游重新定基问题；并使您在未来的道路上遇到更少的冲突合并


听起来您正在考虑编辑发布分支的历史记录。出于短期原因（需要“上游再基地”资源配置）和长期原因（发布分支将不再记录发布的内容），我建议不要这样做。当然，我可能误解了你的建议，所以让我们从一个共同的出发点开始：

您当前有类似于

O --- x --- x --- x --- M2 <--(master)
 \     \               /
  \     x --- M1 --- W1 <--(release)
   \         /
    A ----- B --- C --- D <--(feature)

屈服

                          A' --- B' --- C' --- D' <--(feature)
                         /
O --- x --- x --- x --- M2 <--(master)
 \     \               /
  \     x --- M1 --- W1 <--(release)
   \         /
    A ----- B --- C --- D

A'--B'--C'--D'谢谢您的回复，我已经研究了您所说的内容，并且在主要帖子中更好地解释了情况
                          A' --- B' --- C' --- D' <--(feature)
                         /
O --- x --- x --- x --- M2 <--(master)
 \     \               /
  \     x --- M1 --- W1 <--(release)
   \         /
    A ----- B --- C --- D