git sparse-checkout 的 cone 模式为什么保留根目录文件

只选了 apps/web，工作树里却仍有根目录的 README.md、构建配置和 apps 目录下的文件。cone 模式本来就会保留所选目录的祖先目录中直接包含的文件；它的选择范围不只是 apps/web 这一棵子树。

如果直接改 sparse-checkout 文件，加入不符合 cone 规则的排除表达式，还可能看到：

warning: unrecognized pattern
warning: disabling cone pattern matching

这类警告说明规则不再符合 cone 的形式，不能理解成 Git 已按预想排除根目录文件。

所选目录、祖先文件各有一层范围

按当前 Git 文档，在 cone 模式下选择 apps/web，会保留根目录直接包含的文件、apps 直接包含的文件，以及 apps/web 内任意深度的文件。apps 里的其他子目录不因此全部展开。

即使没有指定任何目录，cone 模式仍包含根目录文件。根目录的包管理配置、构建脚本可能正是子项目运行所需的文件，看到它们并不代表稀疏检出失败。

先从仓库根目录做只读核对：

git --version
git status --short
git sparse-checkout list
git config --show-origin --get core.sparseCheckoutCone

最后一条没有配置时可能返回非零，不能单凭没有输出确定有效模式；结合 Git 版本、选取命令和本地帮助判断。老版本的默认值与当前文档未必相同。

不要往 cone 生成的规则里随意加否定模式

cone 模式输入的是目录列表，Git 在内部转换成受限制的包含、排除模式。手工加入任意 .gitignore 风格规则，会破坏这个结构；模式先后顺序也影响最终包含范围。

需要 apps/web 和上述祖先文件时，保存工作区状态后用命令重新设置目录列表：

git sparse-checkout set --cone apps/web

这会调整稀疏配置和工作树，执行前应保存未提交修改、未跟踪及被忽略的重要文件，并保留原选择。它不会删除提交中的根目录文件，也不能用于“清理掉 Git 多拿的文件”。

确实不能保留根目录文件时

需要任意路径包含、排除规则的是 non-cone 模式。当前文档已将它列为 deprecated，且它不能使用 sparse index；对大仓库还要评估规则匹配开销。因此，应先确认要求是否真的是“工作树不允许出现根目录文件”，而非构建只处理一个子项目。

现有工具链仍支持 non-cone，且已备份状态、确认原规则可恢复时，可按明确的根目录路径设置，例如：

git sparse-checkout set --no-cone --no-sparse-index '/apps/web/'

引号保留模式字面值，这里的斜杠表示仓库路径规则，不能换成磁盘绝对路径。该命令重新定义选取范围，不是追加一条规则；原来需要保留的其他路径要一并考虑。不要通过删除 README.md 或强制重置来模拟稀疏选择。

另外，merge、rebase 等操作可能为了处理冲突暂时展开范围外的文件。有未提交修改或未解决冲突时，先处理并保存这些工作，再考虑 git sparse-checkout reapply，不能因为文件还在就直接清空它们。合并收尾的部分提交错误和大小写路径冲突有各自的处理条件。

修改后核对目录列表、实际路径、工作区差异和构建输入。恢复原选择会再次调整工作树；若改用 git sparse-checkout disable，还会展开全部跟踪文件，应确认磁盘空间。稀疏检出控制本地工作树呈现，不能据此保证下载量、访问权限或远端数据范围。