Git在大小写不敏感文件系统（如macOS APFS、Windows NTFS）上无法重命名仅大小写不同的文件，因文件系统拒绝覆盖同名文件，Git索引仍视其为同一路径；需用临时名称三步重命名或配置core.ignorecase=false并刷新索引。
Git在大小写不敏感文件系统上无法重命名仅大小写不同的文件
你在 macOS 或 Windows 上执行 git mv oldName.js OldName.js 时，Git 报错 fatal: destination exists，或者看似成功但工作区没变化——这不是 Git bug，而是底层文件系统（默认大小写不敏感）拒绝覆盖同名文件。Git 的索引仍认为这是“同一路径”，导致重命名操作被静默忽略或失败。
- 本质是 Git 索引与文件系统语义冲突：Git 认为
readme.md和README.md是两个不同路径，但 macOS 的 APFS/HFS+ 或 Windows NTFS 默认不区分大小写，无法同时存在 - 触发场景常见于从 Linux 仓库拉取后在 macOS 上改名、跨平台协作、或修复历史提交中的大小写错误
- 直接
git add -f强制添加会失败，因为工作区文件未真正重命名，Git 检测不到变更
绕过文件系统限制的三步安全重命名法
核心思路：先让文件在磁盘上“消失”，再以新大小写形式重建，最后通知 Git 更新索引。避免直接 git rm + git add 导致历史丢失。
- 用临时名称重命名文件（确保与原名和目标名都不同），例如：
mv README.md _tmp_README.md - 再用目标名称重建：
mv _tmp_README.md README.md（注意此时大小写已符合目标） - 告诉 Git 这是重命名而非删除+新增：
git add -A && git commit -m "rename README.md (case fix)" - 如果已在暂存区有其他修改，用
git add -u只更新已跟踪文件状态，避免误提交未暂存变更
永久解决：配置 Git 区分大小写并同步全量索引
仅靠手动重命名治标不治本。若团队长期跨平台协作，必须统一 Git 行为，否则每次拉取都可能复现问题。
- 启用大小写敏感模式：
git config core.ignorecase false（⚠️此操作需谨慎，仅对当前仓库有效） - 强制 Git 重新扫描全部文件（清除旧缓存）：
git rm -r --cached . && git add . - 检查是否生效：
git status应显示所有大小写变更文件为 renamed；git ls-files | grep -i "readme"应只返回目标大小写形式 - 注意：若仓库已存在大量大小写混乱文件，
git add .可能报错pathspec 'xxx' did not match any files，需先用git clean -fd清理未跟踪文件再重试
合并分支时遇到大小写冲突的紧急处理
当你 git merge feature-branch 后出现 error: The following untracked working tree files would be overwritten by merge，且文件名仅大小写不同——说明对方分支改了大小写，而你的工作区仍保留旧形式。
- 先备份当前文件（防止误删）：
cp README.md README.md.backup - 放弃本地未提交修改：
git checkout -- README.md（这会恢复为当前分支 HEAD 的版本） - 再执行合并：
git merge feature-branch，此时 Git 能正确识别重命名并应用变更 - 如果已进入冲突状态，用
git ls-files -s | grep -i readme查看索引中实际存储的路径哈希，确认哪一版是目标大小写，再用git checkout feature-branch -- README.md显式检出
最麻烦的情况是双方都改了大小写但方向不同，这时必须人工核对内容差异，用 git show HEAD:readme.md 和 git show feature-branch:README.md 分别查看原始内容再决定保留哪个。
