“fatal: not a git repository”拉取分支时报错主因是core.ignorecase设置与远程仓库不一致，导致索引元数据错乱；需统一设为false（匹配Linux远程环境），再执行git rm -r --cached . && git reset --hard修复索引。
Git拉取分支时提示“fatal: not a git repository”或文件冲突
这不是仓库损坏，而是本地 Git 的 core.ignorecase 设置和远程仓库不一致导致的元数据错乱。常见于 Windows 或 macOS 默认忽略大小写的文件系统上，当你从 Linux 仓库（区分大小写）拉取含大小写混用路径（如 src/utils.js 和 src/Utils.js）的分支时，Git 会卡在索引状态异常，表现为拉取失败、检出报错甚至 git status 显示大量未跟踪文件。
检查并统一 core.ignorecase 值
先确认当前设置：git config --get core.ignorecase
结果为 true 表示忽略大小写（Windows/macOS 默认），false 表示区分（Linux 默认）。关键不是“改成本地系统默认”，而是**必须与远程仓库原始提交历史一致**——通常远程是 Linux 环境提交的，应设为 false。
执行以下命令强制对齐：
GitHub Actions Runtime Regression Audit
下载
对比基线与当前 GitHub Actions 运行导出，在 CI 成本和交付周期激增前及时发现工作流或作业运行时性能退化。
- 如果远程明确区分大小写（绝大多数开源项目、CI 构建环境）：
git config core.ignorecase false - 修改后需重置索引缓存：
git rm -r --cached .git reset --hard - ⚠️ 注意：这会清空暂存区，但不删除工作区文件；若已存在未提交修改，先
git stash
处理已存在的大小写冲突文件
即使设对了 core.ignorecase，旧索引里可能残留冲突项，表现为 git status 中同一路径反复出现“deleted”和“new file”。此时不能直接 git add，否则会覆盖。
安全清理步骤：
- 先备份关键修改（复制整个工作区或用
git stash） - 运行：
git ls-files -s | grep -i "path/to/file"查看索引中重复的大小写条目 - 手动删掉错误条目：
git update-index --force-remove "Src/utils.js"git update-index --add "src/utils.js" - 最后再
git reset --hard同步工作区
避免下次再踩坑
团队协作中，单靠个人配置无法根治问题。真正有效的做法是：
- CI 流水线（如 GitHub Actions）必须使用
runs-on: ubuntu-latest，确保构建环境区分大小写 - 提交前运行检查脚本：
git ls-files | sort -f | uniq -i -d—— 输出即为潜在大小写冲突路径 - 禁止合并含大小写仅差异的文件名（例如
API.md和api.md共存），这类变更必须重命名而非新建
大小写敏感问题不是 Git 的 bug，而是文件系统与版本控制语义的天然张力；修复重点从来不在“让 Git 适应本地”，而在让本地行为收敛到远程事实。
