git config core.filemode false 可让 git 忽略文件权限变更，避免因 macos/linux 权限差异（如 755 vs 644）导致 git status 误报修改而 git diff 无内容差异的伪冲突。
git config core.filemode false 忽略文件权限变更
当团队成员在不同操作系统（比如 macOS 和 Linux）上开发时，git status 常报出一堆“已修改”文件，但 git diff 却看不到内容差异——本质是文件权限（如 755 vs 644）被 Git 当作变更记录了。这种“伪冲突”会干扰真实配置合并，尤其在部署脚本或配置目录中高频出现。
解决方法是让 Git 忽略文件模式（file mode）：
- 全局生效（推荐）：
git config --global core.filemode false - 仅对当前仓库生效：
git config core.filemode false - 验证是否生效：
git config core.filemode应返回false
注意：该设置只影响后续操作，已纳入跟踪的权限变更仍需手动清理。可执行 git add --chmod=-x path/to/file 或先 git reset HEAD path/to/file 再重新暂存。
git config merge.conflictstyle diff3 启用三路冲突标记
默认的冲突标记（ / <code>======= / >>>>>> branch）只展示两个版本，丢失了共同祖先上下文。遇到配置项增删混杂（比如 database.host 在本地删了、远程加了注释、祖先里原本有值），光看两边容易误判。
diff3 模式会在冲突块中插入祖先版本，格式变成：
||||||| merged common ancestors database.host: 127.0.0.1 ======= database.host: prod-db.example.com >>>>>> origin/main
启用方式：
- 全局设置：
git config --global merge.conflictstyle diff3 - 临时单次使用：
git merge -X conflictstyle=diff3 feature/config
这个配置不改变合并逻辑，但极大降低配置类文件（如 application.yml、.env）的手动判断错误率。
git config core.autocrlf false 避免换行符引发的配置污染
Windows 默认用 CRLF（\r\n），Linux/macOS 用 LF（\n）。Git 在检出/提交时若自动转换换行符，会导致配置文件看似“内容未变”，实则二进制层面不同——git diff 显示空白行增减，git status 反复提示修改，合并时还可能触发无意义冲突。
对纯文本配置文件（nginx.conf、docker-compose.yml 等），建议关闭自动转换：
- 跨平台项目统一设为：
git config --global core.autocrlf input（Linux/macOS 推荐）或git config --global core.autocrlf false（完全禁用，最稳妥） - 检查当前值：
git config core.autocrlf - 已污染的文件需重置：
git rm --cached -r . && git reset --hard（慎用，确保工作区干净）
禁用后，所有换行符以仓库原始形态保存，避免因环境差异引入不可见变更。
为什么不能只靠 .gitignore 解决配置冲突
.gitignore 只控制“未跟踪文件”，对已纳入版本管理的配置文件（如 config/database.php）完全无效。常见误区是把生产环境配置写进仓库又试图用 .gitignore “屏蔽冲突”——这会导致 git pull 时直接覆盖本地修改，或报错 Your local changes would be overwritten。
真正适配多环境的解法是分层：
- 模板文件进仓库（如
config/database.php.example） - 实际配置文件名加入
.gitignore（如config/database.php） - 首次部署时复制模板并修改：
cp config/database.php.example config/database.php
此时 Git 完全不跟踪真实配置，自然无冲突。所有配置变更都通过更新模板 + 文档说明驱动，而非直接改 tracked 文件。
配置类冲突的根因往往不在操作步骤，而在 Git 对“什么是变更”的底层判定逻辑。改配置前先确认 core.filemode、autocrlf、conflictstyle 这三项是否符合团队环境，比事后反复 stash/pop 高效得多。尤其当 git status 显示一堆“可疑修改”时，先查这三项配置，大概率直接定位到源头。
