git不支持merge时按路径排除文件，因其操作对象是提交快照而非文件列表；真正有效的方式是通过.gitignore控制跟踪状态，或在冲突阶段用git checkout --ours/--theirs显式选择版本。
Git 本身不提供「合并时自动排除某个文件」的机制。所谓“排除配置文件”，本质是避免把 .gitignore、config.local.php、.env 这类本不该提交或不应随分支流动的文件带进目标分支——这得靠提前约束，而不是靠 git merge 命令临时过滤。
为什么 git merge 不能直接 exclude 某个文件
git merge 操作的是提交（commit）快照，不是文件列表。它对比的是两个分支的共同祖先与各自 HEAD 的差异，然后尝试合并这些变更。你无法在 git merge 命令里加一个 --exclude .env 参数——这个参数根本不存在，Git 也不支持按路径粒度跳过合并逻辑。
- 试图用
git merge --no-commit后手动git checkout HEAD -- .env是危险操作：可能覆盖掉对方分支里合法的、与你无关的.env修改（比如 CI 环境下的模板变更） -
git merge -s ours或-s theirs是按整个提交做策略选择，不是按文件；它会丢弃整条分支的变更，远超“只排除一个配置文件”的需求 - Git 不区分“配置文件”和“代码文件”，它只认 blob 和 tree。所谓“配置文件”只是你约定俗成的语义，Git 无感
真正有效的做法：用 .gitignore + 跟踪状态控制
核心原则：让不该参与版本管理的文件从一开始就不被 Git 跟踪。一旦文件已纳入历史，后续合并就很难干净地“忽略”它。
- 如果
.env还没被提交过：把它加进项目根目录的.gitignore，然后确保没人执行过git add .env——这样它永远不会出现在任何 commit 中，自然也不会出现在 merge 结果里 - 如果
.env已被提交且存在于多个分支：先统一执行git rm --cached .env（仅取消跟踪，保留工作区文件），再提交这次变更。之后所有分支都需同步该提交，否则 merge 仍会触发冲突或重复内容 - 对
config.local.php这类需要存在但内容因环境而异的文件：推荐用模板机制，如提交config.local.php.example，再让部署脚本复制并修改，同时把真实config.local.php加入.gitignore
merge 过程中临时规避冲突的实操底线
当必须合并、但又明确知道某配置文件在两边都有修改且你只想保留当前分支版本时，唯一安全的做法是利用 git checkout 显式重置，且仅限于 merge 冲突阶段：
- 运行
git merge feature/login，出现冲突后不要直接git add - 执行
git checkout --ours -- .env（保留当前分支版本）或git checkout --theirs -- .env（取 feature 分支版本） - 再
git add .env，然后git commit - 注意：
--ours/--theirs只在 merge 冲突期间有效；平时使用等价于HEAD或MERGE_HEAD，不可滥用
最易被忽略的一点：很多人以为 .gitignore 能阻止已跟踪文件的变更进入 merge，其实它只影响 git add 行为。已跟踪文件的修改永远会参与 diff 和 merge——所以“排除配置文件”的起点，永远是让它变成 untracked 状态，而不是指望 merge 命令帮你筛。
