git ls-files 默认输出索引中已被 git 跟踪的文件路径，等价于 git ls-files --cached；未跟踪、已修改未暂存或已删除的文件均不显示。
git ls-files 默认输出的是什么
它只显示当前索引（暂存区）里已被 Git 跟踪的文件，不包括未跟踪、已修改但未暂存、已删除等状态——换句话说，git ls-files 等价于 git ls-files --cached。如果你刚初始化仓库还没 git add 任何东西，这条命令会静默返回空。
常见误解是以为它能“看到所有文件”，其实它默认只看索引，不是工作区快照。想确认某个文件是否已被 Git 记住，直接运行它最可靠；但若发现文件没列出来，别急着改 .gitignore，先查它是不是根本没被 add 过。
怎么区分“已修改但没暂存”和“已暂存但没提交”
关键在参数组合：git ls-files -m 列出工作区已修改、但尚未 git add 的文件；而 git ls-files -s 显示暂存区中每个文件的详细信息，包括 mode、blob hash 和 stage 编号（比如 100644 6cef... 0 file.txt），这才是真正“已暂存”的证据。
-
-m不会显示已暂存后又改过的文件——那种情况得靠git status或git diff -
-s输出里的第三列数字是 stage 编号：0 表示正常暂存，1/2/3 表示合并冲突时的 base/theirs/ours - 如果
git ls-files -s有输出，但git status显示“Changes to be committed”，说明它确实已在暂存区
为什么 git ls-files -i --exclude-standard 没反应
因为 -i（--ignored）必须搭配 -o（--others）或 --cached 才生效，单独用会被忽略。正确写法是：git ls-files -o -i --exclude-standard，否则命令不报错也不输出。
监控一个或多个 GitCode 仓库的 PR，通过 OpenClaw Gateway 自动执行 AI 审查，发布 PR 评论，并发送钉钉和企业微信通知。
这个组合实际含义是：“列出所有未跟踪（-o）且被忽略（-i）的文件”，也就是你删掉临时构建产物前最该扫一眼的列表。容易踩的坑还有：
- 项目根目录下没有
.gitignore，或规则写错路径（比如漏了/导致子目录不生效） - 文件曾经被
git add过，现在即使匹配.gitignore也会继续被跟踪——此时git rm --cached <file></file>才是解药 -
--exclude-standard只加载全局 + 项目级 + 目录级.gitignore，不会读.git/info/exclude，要查这个得加--exclude-from=.git/info/exclude
用 ls-files 查大文件或 LFS 跟踪状态
查仓库里哪些文件对象体积大，核心是结合 -s 输出解析 blob size：git ls-files -s | awk '{if ($3 >= 1000000) print $3, $4}'。注意第三列是 size，第四列才是文件名（因为 -s 输出格式固定为 “mode blobhash stage filename”）。
对 Git LFS 用户，git lfs ls-files 是独立命令，不能混用 git ls-files 参数。它只显示当前索引中被 LFS track 的文件指针（pointer files），不显示原始二进制内容。如果执行后为空，说明要么没 git lfs track，要么 track 后没 git add 对应文件。
真正难处理的是 LFS 文件被删但指针残留的情况——这时 git lfs ls-files 还会显示它，但 git push 会报 [404] Object does not exist on the server。这种必须手动清理远程 LFS 存储，本地无法修复。
