我可以使用一些帮助来制定恢复策略。不知何故,我们最终处于一个提交丢弃了大约 3 天的提交的位置。然后被推了。提交者不确定他是强制推送还是什么,但现在我们处于这个位置。自“坏”提交以来,已经推送了大约 10 个额外的提交。
所有旧的提交都在那里,我可以将所有内容重新组合在一起,但我希望 Git 可以帮助我。我想我可以挑选 A 点和 B 点之间的提交范围,但还有什么更好的吗?大多数(但不是全部)更改都位于一个目录的本地,我宁愿不手动检查每一个。
记住一切都被推到了上游,这里的正确方法是什么?
我可以使用一些帮助来制定恢复策略。不知何故,我们最终处于一个提交丢弃了大约 3 天的提交的位置。然后被推了。提交者不确定他是强制推送还是什么,但现在我们处于这个位置。自“坏”提交以来,已经推送了大约 10 个额外的提交。
所有旧的提交都在那里,我可以将所有内容重新组合在一起,但我希望 Git 可以帮助我。我想我可以挑选 A 点和 B 点之间的提交范围,但还有什么更好的吗?大多数(但不是全部)更改都位于一个目录的本地,我宁愿不手动检查每一个。
记住一切都被推到了上游,这里的正确方法是什么?
git reset --hard <one commit before the bad commit>
git cherry-pick <the range of commits you've lost>
git pull
通过这种方式,您可以模拟您正在进行最后一次良好的提交(使用reset
)。然后在本地创建新的提交 ( cherry-pick
)。现在您引入更改(可能还有合并冲突)。
您可能有兴趣检查git reflog
上游或本地存储库。即使提交看起来像是丢失了,它们实际上可能仍然在您的远程/本地存储库中徘徊,只是没有分支指针。他们不会永远保持这种状态,我认为 git默认每 2 周进行一次垃圾收集:
可选配置变量 gc.pruneExpire 控制未引用的松散对象在被修剪之前必须存在多长时间。默认值为“2 周前”。
您可以在Pro Git §9.7:维护和数据恢复中阅读有关使用 reflog 恢复丢失工作的更多信息。
如果您在 reflog 中找到提交(或者您可能还想在 中查找它们git fsck --full
),您可以将分支指针附加到它们以“恢复”它们。然后,您可能想要rebase
或cherry-pick
更新的提交,以便(重新)构建您想要的任何提交历史树。
git revert
将在新提交中撤消提交的更改。