Git:在推送后恢复意外丢弃文件的 merge

Question

没有经验的用户进行更改 release然后 merge 到dev .哦不， merge 冲突! merge 状态显示他们自己的冲突文件，以及其他团队成员的所有其他修复。作为一个偏执和谨慎的用户，他们说:

Those aren't my files, did I accidentally alter them? Aha, I should discard them!

merge 提交现在只包含他们的更改，丢弃分支中的所有其他更改(可能需要大量工作)。他们推dev上游，错误逃脱了检测，直到另一个团队成员注意到有什么不对劲。

大多数指南建议:

1. 如果尚未推送分支:git reset
2. 还原 merge :git revert -m 1 <commitId> .然而，这只会恢复数据(也就是不幸的用户所做的更改)，它不会撤消历史记录。任何 future 的尝试 merge将忽略丢失的更改，因为历史表明它们已经集成。
3. 改写历史，rebase或 reset其次是 git push origin -f .这意味着团队的其他成员必须同步到强制 dev分支。如果团队很大，或者错误没有被迅速发现，或者存在复杂的 CI 工具——这将成为一个非常痛苦的练习。

恕我直言，这让我对 git 的设计产生了严重的疏忽。几乎没有工具可以识别这种情况或从中恢复。 git diff不显示丢弃的更改，并且 git revert不会撤消那些丢弃的更改。有没有更好的方法来预防和解决这个问题？

Answer 1

如 Linus ( https://mirrors.edge.kernel.org/pub/software/scm/git/docs/howto/revert-a-faulty-merge.txt ) 所详述:

Reverting a regular commit just effectively undoes what that commit did, and is fairly straightforward. But reverting a merge commit also undoes the data that the commit changed, but it does absolutely nothing to the effects on history that the merge had.

So the merge will still exist, and it will still be seen as joining the two branches together, and future merges will see that merge as the last shared state - and the revert that reverted the merge brought in will not affect that at all.

So a "revert" undoes the data changes, but it's very much not an "undo" in the sense that it doesn't undo the effects of a commit on the repository history.

好的，这就解释了为什么 revert 不是一个有效的策略，但是我们能做什么呢？让我们考虑以下几点:

p---Q---r---s---M---t---u---   dev
     \         /
      A---B---C-------D---E    feature

• ABC 是功能/发布分支​​工作
• M 是错误的 merge ，来自 AB 的更改被丢弃，但 C 被保留
• DE 稍后用于功能
• 其余是主线分支dev上不相关的改动

只要 M 存在于 dev 上，它就假定 ABC 的历史已经集成，即使 AB 的增量缺失。要在不更改 dev 的历史记录的情况下恢复它们，我们需要在备用历史记录(即新的提交 ID)中重新创建增量。

如果只有几个提交，您可以将每个提交单独 cherrypick 到 dev 中，因为 cherrypicking 会将数据复制到新的提交 ID 中。然而，这不能很好地扩展到大型或复杂的分支历史。

下一个选项是使用 rebase --no-ff 重新创建一个新的 feature 分支，可以从中 merge 丢失的更改。

git checkout E
git rebase --no-ff Q

创建以下内容:

      A'--B'--C'-------D'--E'    feature-fixed
     /                      \
p---Q---r---s---M---t---u---M2   dev
     \         /
      A---B---C--------D---E     feature

最初的 merge M 可能只是由于 merge 冲突而成为问题。这种方法的一个问题是，您不仅必须正确解决 ABC 中的原始冲突，而且现在您还有一个新的可能的 DE 和 TU 冲突源需要应对。在紧急情况下，这可能很难弄清楚发生了什么。

首选解决方案:

p---Q---r---S-------M---t---u-----M3      dev
     \       \     /              /
      A---B---\---C----D---E     /        feature
               \   \            /
                ----M2----------          fix

使用您可能熟悉的工具的更简单策略是使用 squash 提交 (M2) 正确地重新创建 merge 。这会创建一个新的提交 ID(新的历史记录)，因此来自 AB 的增量可以成功地集成回主线。此方法还关闭了 merge 冲突的可能来源，允许您首先纠正错误，然后处理上游更改。

方法:

在错误 merge (M) 着陆之前从 dev 分支。

git checkout -b fix S

您现在有了一个干净的平台，您可以从中执行更正的 merge 。 squash 标志会将这些更改压缩到一个提交中，但更重要的是它会生成一个新的提交 ID

git merge --squash C

此时您可能需要解决冲突，但是 M2 现在代表 M 最初应该包含的所有数据。您现在可以像往常一样将它 merge 到 dev

git checkout dev
git merge fix

同样，可能会出现 merge 冲突，但在这一点 (M3) 之后，您已经恢复了丢失的数据。您现在可以自由地按照正常方式进行，例如，您可以自由地将 DE 从 feature merge 到 dev 或任何其他常规操作。这也意味着其他团队成员不需要重置他们的本地 dev 分支，因为它会在他们下次执行 pull 时恢复。