GitHub 无法识别来自还原的拉取请求的更改答案

【问题标题】：GitHub does not recognize changes from a reverted pull requestGitHub 无法识别来自还原的拉取请求的更改
【发布时间】：2017-01-07 01:06:52
【问题描述】：

我正在开发一个名为 bug-fix-1 的 Git 分支，它是基于 integration 分支创建的。还有另一个分支 bug-fix-2 被合并到 integration 分支中，然后我们恢复了更改（全部在 Github 上完成）。

现在，当我提出一个新的拉取请求以将我的 bug-fix-1 合并到 integration 时，我希望看到我从 bug-fix-2 中提取的更改。但是不，我看不到任何一个，拉取请求只显示我在bug-fix-1 上所做的更改。

关于如何将更改从 bug-fix-2 拉入我的分支并将它们合并到 integration 的任何解决方案？

【问题讨论】：

【解决方案1】：

这是 Git 的一个有趣的特性，一旦你意识到发生了什么，它并不是一个糟糕的特性。

Git 通过提交哈希跟踪提交，并且从历史记录中hot-fix-2 已经存在。 Git 也知道已经应用了还原，但它并没有真正将其视为撤销原始提交。相反，它只是另一个碰巧反向应用相同差异的提交，并且它也有自己的提交哈希。

为了让 Git 看到更改，您有以下几种选择之一：

还原还原。听起来很奇怪，但它确实有效。这表示要引入一个包含反向差异的新提交。集成分支上不存在该提交，因此 Git 会将其视为要引入的更改。
您可以挑选原始提交，但您需要一个特殊选项：
```
git cherry-pick --keep-redundant-commits COMMIT_HASH
```
COMMIT_HASH 引入了原始错误修复。

还有其他方法可以帮助做到这一点，但它们有点复杂，并且涉及使用git rebase。我认为上述技术可能是最直接的。

【讨论】：

我个人更喜欢git checkout bug-fix-2 && git rebase integration，但如果有任何合并冲突......（1）可能是最好的选择。
那行不通。它将放弃提交，因为它已经存在于集成分支中。
不起作用，我尝试使用cherry-pick，但在git中没有看到任何行更改。将进一步阅读 --keep-redundant-commits 行为，但就推迟恢复的更改而言，这不是解决方案。
@mibbit 您必须提供有关正在发生的事情的更多上下文。它绝对有效，但我怀疑您的特定设置有些不同，这对您来说会有所不同。例如，您可能认为指定分支名称将选择该分支上的所有提交，但事实并非如此。您能否在 GitHub 上提供 Gist 并提供问题示例？我还要补充一点，Git 似乎在某些方面变得更聪明了（我必须深入研究它），在过去的情况下你可能不需要这个选项。
@mibbit 还请记住，如果以其他方式引入了相应的修复程序（也许其他人修复了问题），那么可能会忽略差异的那部分，或者提交可能会全部丢弃如果这是全部精选提交（没有 --keep-redundant-commits 并且您应该看到警告，除非您将它们关闭）或者您可能有一个空提交（使用 --keep-redundant-commits）。