git合并时无法真正“忽略”已跟踪文件，唯一有效方案是用.gitattributes+merge=ours策略保留当前分支版本，或git merge --no-commit后手动重置文件；.gitignore对已提交文件完全无效。
Git 本身没有「合并时自动跳过某文件」的原生开关。所谓“忽略特定文件的修改”，本质是控制该文件在合并后最终保留哪个版本——要么留当前分支的，要么留被合并分支的，或者手动干预。关键不在“跳过”，而在“策略选择”和“时机控制”。
用 .gitattributes + merge=ours 锁定保留当前分支版本
这是最接近“真正忽略”的方案，适用于配置文件、环境标识等必须保持分支独立性的场景。它让 Git 在发生冲突或需合并时，直接采用当前分支（ours）的内容，不拉取对方修改。
- 在项目根目录创建或编辑
.gitattributes，添加规则，例如：infostation.js merge=ours
- 全局注册
ours合并驱动：git config --global merge.ours.driver true - 确保
.gitattributes已提交到所有相关分支，否则只在当前分支生效 - ⚠️ 注意：如果文件从未被 Git 跟踪过（即未
git add过），该策略无效；它只对已跟踪文件起作用
用 git merge --no-commit 手动丢弃不需要的变更
这是最可控、最常用的方式，适合一次性操作或 CI/CD 流程中明确排除某些文件。它不依赖配置，靠命令组合完成“先合并、再清理、最后提交”。
- 执行：
git merge --no-commit feature-branch，此时变更已应用但未提交 - 恢复指定文件为当前分支内容：
git checkout HEAD -- infostation.js - 或恢复为被合并分支内容：
git checkout feature-branch -- infostation.js - 确认暂存区状态：
git status，确保目标文件已重置到位 - 提交：
git commit -m "Merge feature-branch, keep infostation.js unchanged" - ⚠️ 注意：如果文件在被合并分支中被删除，
git checkout HEAD --会把它“救回来”，这可能不是你想要的；此时应改用git restore --staged --worktree --source=HEAD -- infostation.js（Git 2.23+）
别误用 .gitignore 来“合并时忽略”
.gitignore 只影响未跟踪文件的自动添加（git add .），对已跟踪文件的合并行为完全无影响。很多人在这里踩坑，以为加了 config.js 就能阻止它被合并——实际毫无作用。
- 已提交过的
config.js，无论.gitignore怎么写，都会参与合并 - 想让它“不参与”，唯一办法是先从 Git 索引中移除：
git rm --cached config.js，再提交。但这等于放弃对该文件的版本控制，后续任何分支都无法同步它的变更 - 若只是临时跳过某次合并，
.gitignore不是解法；它属于长期策略，且代价是失去协同一致性
真正难的不是操作步骤，而是判断：这个文件是否真的该“忽略修改”？如果是环境配置，.gitattributes 是首选；如果是临时生成物，应该从源头杜绝提交；如果只是某次发布想绕开某个 bug 文件，--no-commit 手动处理最稳妥。所有方法都绕不开一个事实——Git 的合并是内容快照比对，不是路径白名单过滤。
