无法恢复的 git 推送？
我仍在尝试了解 rebase 和重写 Git 历史的后果。想象一下 github 上的一个存储库 R，其中包含一年的宝贵源代码历史记录。假设这是地球上唯一的副本。
提交者是否可以通过克隆存储库、进行一些更改并将其推回来执行某些操作，这会导致该存储库永久丢失？我不知道，一些奇怪的变基、删除、推送序列？如果是这样，是否有任何这样的序列是立即不可逆转的（而不是在垃圾收集之后一个月左右发生）？
I'm still trying to understand the ramifications of rebase and rewriting Git history. Imagine a repository R on github with a year's worth of valuable source code history. Let's say it's the only copy on the planet.
Are there things a committer could do, by cloning the repository, making some changes, and pushing them back, that would cause permanent loss in that repository? I don't know, some weird sequence of rebases, deletes, pushes? And if so, are there any such sequences that would be irreversible immediately (rather than taking place a month or so later, after garbage collection)?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
默认情况下，非快进推送会被服务器拒绝。不过，从 git-push 手册页，你可以找到一种强制的方法服务器接受潜在破坏性的推送操作：
正如警告所述，这可能会导致远程丢失一个或多个提交。具体来说，如果无法从另一个分支的 HEAD 访问目标分支的提交，则可能会发生这种情况。
例如，以下情况可能会导致服务器丢失提交：
但是，如果您刚刚尝试覆盖的提交碰巧被标记或可以从另一个分支的 HEAD 访问，则该提交不会丢失。
By default, non fast-forward pushes are rejected by the server. However, from the git-push man page, you can find a means to force the server to accept a potentially destructive push operation:
As the warning says, this may cause the remote to lose one or more commits. Specifically, this may happen if the destination branch's commit is not reachable from another branch's HEAD.
For example, the following scenario may cause the server to lose a commit:
However, if the commit you just tried to overwrite happened to be tagged or accessible from another branch's HEAD, the commit will not be lost.
如果强制推送到存储库，某些提交可能无法访问，正如 André Caron 所解释的那样。
Github 不允许您访问存储库（因为这不完全是标准的 git 存储库，而且这不关您的事）。所以在这种情况下，您实际上会丢失信息。
但是，如果您是此存储库的有效管理员，则在某种程度上，您可以通过浏览引用日志来从强制推送中恢复，然后使分支恢复生机。
请注意，您的本地存储库（您从中强制推送的存储库）应包含将丢失的提交，然后您应该能够在需要时恢复它们。
If you force push to a repository, some commits could be unreachable as André Caron explained.
Github don't let you access the repository (because this isn't exactly a standard git repository and because this is not your business anyway). So in this case, you'll actually loose information.
But if you are the effective administrator of this repository, you're able, at some extent, to recover from a force push by browsing the reflog and then bring branches back to life.
Please note that your local repository (the one you made the force push from) should containt the to-be-losed commits and then you should be able to resurrect them if needed.
是的，某些操作将永久销毁您的历史记录，例如：
将用丢失主历史记录的本地分支覆盖您的主存储库（repo-name）。
但是，破坏历史记录的最常见方法是通过交互式变基：
...仅在尚未推送到外部存储库的提交上执行此操作。如果其他人的工作基于您要删除的提交，则可能会发生大量冲突。如果您的历史记录已与他人共享，请不要重写。
我建议阅读更多内容：
http://gitready.com /advanced/2009/02/10/squashing-commits-with-rebase.html
http://progit.org/book/ch6-4.html
http://book.git-scm.com/4_interactive_rebasing.html
Yes, some operations are going to destroy permanently your history, for example :
will overwrite your master repo ( repo-name ) with local branch loosing master history.
But the most common way to trash your history is by interactive Rebasing:
... only do this on commits that haven’t been pushed an external repository. If others have based work off of the commits that you’re going to delete, plenty of conflicts can occur. Just don’t rewrite your history if it’s been shared with others.
I reccomend to read more :
http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html
http://progit.org/book/ch6-4.html
http://book.git-scm.com/4_interactive_rebasing.html