Question

我仍在努力了解rebase的影响并重写Git历史。想象一下github上的一个存储库R，它有一年的宝贵源代码历史。让我们说它是这个星球上唯一的副本。

提交者可以做些什么，通过克隆存储库，进行一些更改并推回它们，这会导致该存储库永久丢失？我不知道，一些奇怪的重复，删除，推动的序列？如果是这样，是否有任何此类序列立即不可逆转（而不是在垃圾收集后一个月左右发生）？

Answer 1

默认情况下，服务器会拒绝非快进推送。但是，从git-push man page，您可以找到一种方法来强制服务器接受可能具有破坏性的推送操作：

-f， - force

通常，该命令拒绝更新不是本地祖先的远程引用   ref用来覆盖它。此标志禁用检查。 这可能会导致遥控器   存储库丢失提交;小心使用。

正如警告所说，这可能会导致遥控器丢失一个或多个提交。具体而言，如果无法从另一个分支的HEAD访问目标分支的提交，则可能会发生这种情况。

例如，以下方案可能导致服务器丢失提交：

git clone ...
edit ...
git add .
git commit --amend -m "These changes overwrite origin/master's HEAD."
git push -f origin master

但是，如果您刚刚尝试覆盖的提交恰好被标记或可从另一个分支的HEAD访问，则提交不会丢失。

Answer 2

如果强制推送到存储库，AndréCaron解释说，某些提交可能无法访问。

Github不允许您访问存储库（因为这不是一个标准的git存储库，因为这不是您的业务）。所以在这种情况下，你实际上会丢失信息。

但是如果你是这个存储库的有效管理员，你可以在某种程度上通过浏览reflog从强制推送中恢复，然后让分支恢复生机。

请注意，您的本地存储库（您强制推送的存储库）应该包含待处理的提交，然后您应该能够在需要时复活它们。

Answer 3

是的，某些操作会永久破坏您的历史记录，例如：

git push repo-name +master

将使用本地分支丢失主历史记录覆盖主仓库（repo-name）。

但废弃历史记录的最常见方式是通过互动式重新定位：

git rebase -i 6bd80e12

...仅在尚未推送到外部存储库的提交上执行此操作。如果其他人的工作基于您要删除的提交，则可能会发生许多冲突。如果已经与他人共享，请不要重写您的历史记录。

我建议您阅读更多内容：