Git恢复灾难[重复]答案

【问题标题】：Git revert catastrophe [duplicate]Git恢复灾难[重复]
【发布时间】：2016-03-08 13:50:31
【问题描述】：

考虑以下情况。

我有两个分支：main 和 main_feature_#1。

我创建了一个拉取请求并将main_feature_#1 合并到main。我发现了一些合并问题，没有出路——不得不revert这个合并；在本地完成并推送。
签出 main_feature_#1 并还原其中一个提交。

现在，当我打开 main 与 main_feature_# 的拉取请求时，显示的唯一提交是在 main_feature_# 上进行的最后一次还原。从main_feature_#1 到main 的本地合并也显示了同样的情况。 git diff main main_feature_#1 显示了所有的变化。

但是，main_feature_#1 与 main 的拉取请求显示了正确合并的所有差异。

我不知道该怎么办了。 :(

【问题讨论】：

你先还原revert吗？
你的意思是我必须恢复我在main 上所做的恢复？为什么？
或者你从技术上说我不应该从一开始就恢复合并。刚刚恢复了 main_feature_#1 中的某些内容，然后打开了一个新的拉取请求。
main_feature_#1 是一个糟糕的 git 标识符名称。 # 字符是 Unix shell 中的注释字符，因此要在 Unix 命令行中正确使用标识符，您必须始终引用 # 字符或整个标识符。
Here's a reference to what I'm talking about. 听起来你的场景是相同的（main_feature#1 的所有更改都会出现在你的分支上；碰巧稍后提交进来并反转了他们的添加。这并不是合并从未发生过。）

标签： git github

【解决方案1】：

这是合并还原的常见问题。有几种方法可以修复它。最简单的方法是使用 git cherry-pick 重新重新应用这些提交，但在较长的分支历史上可能会很乏味。我通常使用所有三个参数 git rebase --onto main_feature_#1 <start of the main_feature_#1> <first commit before the unwanted merge> --interactive 进行 rebase。

【讨论】：

这会让事情变得更糟。
@Makoto 如果分支很简单，则不会。否则，您可以随时重置。
请在 cmets 中查看 @Makoto 的回答。它几乎接近完美，而且非常干净。