我有一个项目，我用Git LFS存储视频文件。现在我遇到了一些不支持Git LFS的构建服务器的并发症。由于它是一个外部服务，我不能真正影响构建过程，因此希望将文件从Git LFS下移回“常规”Git。我设法用git lfs untrack '<file-type>'解开文件类型，但git lfs ls-files仍然提供了之前添加的文件列表。
我想我可以删除文件，推送更改然后手动重新添加它们，但这是否真的是推荐的做事方式？
我刚刚遇到这个问题，资产被意外地添加到一个不应该的分支上的git-lfs。我的解决方案是：
git lfs untrack '<file-type>'
git rm --cached '<file-type>'
git add '<file-type>'
git commit -m "restore '<file-type>' to git from lfs"
结果是重写了带有标准文件内容的git-lfs oid sha256指针。
（编辑2019-03）：已接受的答案已更改，以便为更简单的案例提供简单的解决方案。如果您手头有更复杂的案例，另请参阅edits in the answer by VonC了解替代解决方案。
Issue 641提到了同样的问题。
我试图停止使用Git LFS，但发现没有办法使用
git lfs uninit，git lfs untrack，git rm恢复我之前跟踪的指针文件...在我移动这些文件之后仍然列出由Git LFS跟踪git lfs ls-files，我怎么能选择退出我的回购中的整个Git LFS东西？
答案是：
- 使用
git lfs uninit删除所有filter.lfs。* git config条目。- 通过为每种文件类型运行
.gitattributes清除在git lfs untrack中使用lfs过滤器的任何属性，或者如果LFS是您曾经使用过的，则删除.gitattributes。
在此之后，任何添加的文件将直接进入git。
但这不是那么简单：
我后来在我的工作目录中结束了LFS指针文件，并且必须使用手动存储在这些指针中的sha1哈希从
.git/lfs恢复我的所有图片。
2016年3月更新，issue 957说明了tstephens619可能的解决方案：
我犯了同样的错误，将几种小图形格式包含在我的
git lfs跟踪列表中。 我可以通过执行以下操作将此文件移回git：
- 创建
git-lfs当前正在跟踪的所有文件的列表，过滤掉*.gz和*.rpm（我想仍然使用git-lfs跟踪这些扩展）git lfs ls-files | grep -vE "\.gz|\.rpm$" | cut -d ' ' -f 3 > ~/temp/lfs-files.txt- 停止跟踪小图形文件
git lfs untrack "*.tts" git lfs untrack "*.bfx" git lfs untrack "*.ttf" git lfs untrack "*.xcf" git lfs untrack "*.pkm" git lfs untrack "*.png"- 暂时uninit
git-lfsgit lfs uninit # Git LFS 2.x+ git lfs uninstall- 使用文件列表触摸每个文件：
cat ~/temp/lfs-files.txt | xargs touch
git status现在将每个文件显示为已修改
- 将更改添加到git索引（我是通过
git gui完成的）- 提交更改，然后重新初始化git-lfs
git commit git lfs init
一种方法是：
for file in $FILES_TO_REVERT; do
git lfs untrack "$file";
git rm --cached "$file";
git add --force "$file";
done
git commit -m "..."
我的偏好是不会向Git LFS添加一个命令以达到上述效果，因为它可以通过Git和Git LFS提供的瓷器命令以多种不同的方式实现。
As of Git 2.16（2018年1月17日发布），你可以使用--renormalize的git add旗子轻松完成：
git lfs untrack '<pattern>'
git add --renormalize .
git commit -m 'Restore file contents that were previously in LFS'
--renormalize：将“clean”进程新近应用于所有跟踪的文件，以强制将它们再次添加到索引中。在更改
core.autocrlf配置或text属性以更正添加了错误CRLF / LF行结尾的文件后，这很有用。这个选项意味着-u。
这里的关键部分是“所有跟踪文件”。通常，只有在Git操作更改工作树中的文件时才会运行过滤器。更改.gitattributes中的LFS白名单不是Git操作，因此在运行git lfs untrack后索引最终会处于不一致状态。运行git add --renormalize .告诉Git重新运行存储库中每个文件的过滤器，这确保了应该在LFS中的所有文件都是 - 并且所有不应该的文件都不是。
我在Windows中执行某些步骤时遇到问题。要删除所有git lfs跟踪文件并恢复原始文件，我在git bash中执行了以下操作：
git lfs ls-files | cut -d ' ' -f 3 > lfs-files.txt片段：
while read file; do
git lfs untrack "$file";
git rm --cached "$file";
git add --force "$file";
done <lfs-files.txt
您无法从GIT LFS中删除任何内容，虽然此处提供的解决方案可能有效（经过修改），但它们需要付出很多努力，并且可能会对您的存储库产生副作用。
如果你到了这里，是时候问问自己是否要用GIF LFS管理你的大文件，以及GIT本身（管理大文件本质上是不好的，因为它是一个分布式版本控制系统）是一个不错的选择。
如果您有许多大型文件，并且您是一个处理项目的组织，那么像Subversion这样的东西可能会更好地为您服务。