所以这就是发生的事情：
git reset --soft HEAD~2在事故发生前回到了提交我认为git reset会从意外提交中撤消所有内容，但在检查了bitbucket的git lfs文件列表后，似乎所有来自意外提交的lfs跟踪文件都被推送到lfs in origin。如果我查看bitbucket中的源代码，这些文件就不存在了。
所以我尝试了git lfs prune，它似乎删除了一些看起来与意外提交的数量有关的文件，然后是git lfs push origin master。再次检查了bitbucket的git lfs文件列表，但这些文件仍然存在且原始状态没有任何变化。
我做错了什么？
答案 0 :(得分：6)
有doesn't appear to be a standard way of doing this：
Git LFS命令行客户端不支持从服务器修剪文件，因此删除它们的方式取决于您的托管服务提供商。
Bitbucket allows you to delete LFS files using its web UI（ 请 在继续之前阅读整个链接页面）：
从存储库中删除单个LFS文件
了解这一点非常重要：
- 这里描述的删除操作是破坏性的 - 没有办法恢复被删除的LFS指针文件引用的LFS文件（它不像git remove命令！） - 所以你需要先备份LFS文件。
- 删除LFS文件只会将其从远程存储中删除。存储在Git仓库中的所有参考指针都将保留。
- 以后没有分支，标签或修订版能够引用LFS文件。如果您尝试签出包含引用已删除的LFS文件的指针文件的分支，标记或修订，您将收到下载错误，并且签出将失败。
存储库管理员可以从存储库中删除Git LFS文件，如下所示：
- 转到repo的Settings页面，然后单击Git LFS以查看该repo中所有LFS文件的列表。
- 使用操作菜单删除LFS文件。
令人惊讶的是，从GitHub中删除LFS文件的唯一方法似乎是delete and recreate the repository，丢失问题，星标，分叉以及可能的其他数据。
答案 1 :(得分：2)
在您遵循的最初步骤中，我认为您只是偶然发现git / git-lfs集成并不总是完全无缝的情况。
reset命令会将您的分支引用移回。它实际上不会删除不需要的提交（或相关对象）;但这通常无关紧要，因为这些对象无法访问，因此不会与push一起发送。到目前为止，这很好......还有香草git。
但是：在推送之前，LFS对象（大文件的真实内容）也没有被删除。 AFAIK（你的经验似乎证实了这一点）LFS做不试图确定推送到遥控器时是否可以访问LFS对象 - 毕竟这似乎是一个昂贵的检查。鉴于您的LFS存储区旨在容纳一堆大型二进制文件，并且LFS旨在降低LFS存储中大量不需要的数据的成本，因此成本效益通常有利于发送任何不需要的数据。在服务器上 - 这显然发生在这里。
除非您在服务器上面临物理存储限制，否则可能确实如此。没有获取或拉动 - 没有明确告诉LFS向您发送所有内容（不适合正常使用） - 无论如何都会导致这些文件被下载。
但也许你的repo主机遇到了存储限制。或者也许你只是想让它们消失;我不能说我会怪你。在本地删除文件并推送不会导致文件从服务器中删除也是设计上的。 （对于核心git对象也是如此;您可以强制推送ref以使远程对象无法访问，但物理上“清理”远程对象不依赖于任何本地清理。）
有关从bitbucket托管的仓库中删除LFS文件的信息，请访问：https://www.atlassian.com/git/tutorials/git-lfs#deleting-remote-files
答案 2 :(得分：1)
对于BitBucket用户，我有一个解决方案，该解决方案已经可以使用几个月了： https://gist.github.com/danielgindi/db0e0a897d8d920f23e155bb5d59e9c6
基本上，您可以在Bitbucket存储库中打开Chrome并登录，然后将这段代码放入控制台。它使用您的授权来删除所有早于指定时间的LFS文件，这需要几秒钟的时间。
重要提示：切勿在浏览器中盲目地运行任何代码。查看代码，确保您了解它的作用。我可以告诉你“相信我”，但是你不认识我。