git 之前错误的合并阻止了变基 - 可以修复吗？

Question

我想我知道这个问题的答案，但我想检查一下，希望我是错的。

我们在一个分支上做了很多工作，我打算将它作为一个 rebase 与 master 合并，这样一旦所有的部分都到位，我们所有的历史就会被保留下来。我提出了一个拉取请求，其中一位审阅者批准了它并进行了“挤压和合并”。无论如何，合并还为时过早，我们恢复了对 master 的更改，但这使得新目录在 master 上具有历史记录。现在没有“Rebase and Merge”选项（github 已将其灰显）。我试图将分支变基以在本地掌握它，但它失败了，错误指向删除了以前合并的文件的提交。

我已经用尽了我的 git-fu。有没有办法摆脱 master 手术和强制推动的短缺，考虑到拥有 repo 的人数，这不太可能飞行？

Answer 1

Is there a way out of this short of surgery on master

从某种意义上说，不。从所谓的 Squash and Merge（我之所以这么说是因为 Squash and Merge 实际上不是任何一种合并）的那一刻起，就从来没有过。你所做的，恢复，forward;它甚至增加了 more 提交。 “撤消”实际历史记录的唯一方法是重置。那就是你倒退的方式。对已推送的 material 进行重置的唯一方法是强制推送。

但是，我也不会说一切都失去了。当然，您的历史很乱，但那又怎样？在这一点上，这只是历史上的一个小故障；总有一天它会消失在时间的沙滩上。重要的是 now 是 master — 意思是，在任何人进行任何类型的合并之前对 master 的最后一次提交 — 应该处于正确的状态（我的意思是，所有文件的正确状态）。所以只要安排那个状态，不管它是什么，然后把它提交到master，然后继续。

我也想说，我不同意问题的前提。你说：

I had intended to merge this [branch] with master as a rebase so that all of our history would be retained once all the pieces were in place

错了。 “合并为变基”不会“保留历史”。关于历史，它谎言。保留分支历史的方法是 merge 分支，简单明了。 Rebase 不是合并；壁球不是合并； merge 是合并。合并很好。它们是保留发生的事情的最干净的方式，同时使未来有可能顺利地发展。（举个例子，如果你做了一个真正的合并，然后如果你发现合并为时过早，你可以继续在分支上工作，修复它，然后再次合并它。事情就是这样，正如你所发现的, 没那么简单。)

Answer 2

如果我没理解错的话，你的情况是这样的：

             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 中的文件状态足够接近开始修改它们，这可能会在没有太多冲突的情况下工作。这在很大程度上取决于 other 对 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 历史记录的开头（直到提交 s）。

git 之前错误的合并阻止了变基 - 可以修复吗？

git rebase prevented by mistaken previous merge - can it be fixed?

git

github

git-merge

git-rebase