merge=ours 是唯一可靠方案：先全局注册 git config --global merge.ours.driver true，再在项目根目录创建已提交的 .gitattributes 文件，精确声明如 config/database.yml merge=ours，确保目标分支存在该文件的历史记录以触发三方合并。
git merge 时 config.yml 总被覆盖？别碰 .gitignore
.gitignore 对已提交过的 config.yml 完全无效——它只管“没进过 Git”的新文件。你加了规则却依然被合并，说明该文件早就在历史里被 git add 和 commit 过。真正起作用的只有 Git 的三方合并机制，不是忽略列表。
关键判断：只要文件在两个分支都改过，Git 就会触发三方合并；此时 .gitattributes 中的 merge=ours 才生效。如果仅 source 分支改了而 target 分支没动过，merge=ours 不触发，文件照常合入。
- 先确认文件状态：
git ls-files --stage | grep config.yml—— 有输出即表示已被跟踪 - 检查是否真有双侧修改：
git log --oneline -p main..feature -- config.yml和git log --oneline -p feature..main -- config.yml - 若仅单侧有变更，需在 target 分支（如
main）也做一次无意义提交（比如加空行），再合并才能激活merge=ours
配置 .gitattributes + merge.ours.driver 是唯一可复用方案
这是唯一能写进项目、随分支流转、团队无需额外操作的方案。核心就两步：注册驱动、声明策略。
执行以下命令（全局只需一次）：git config --global merge.ours.driver true
在项目根目录创建 .gitattributes，内容示例：
config/database.yml merge=ours src/main/resources/application.properties merge=ours .env.local merge=ours
注意：.gitattributes 必须提交到所有参与合并的分支（main、develop、release/*），否则策略不生效。
- 路径必须精确匹配：用
/config/database.yml而非config/database.yml可能失效（Git 对前导斜杠敏感） - 通配符慎用：
*.yml merge=ours会作用于所有 yml 文件，包括本不该跳过的文档 - 策略只对文本文件有效；二进制文件需额外配置
merge=binary，但ours不适用
git merge --no-commit 后手动 reset 是临时救急法
适合 CI/CD 流水线外的一次性发布，或策略未提前部署时的补救。它不改变历史，也不依赖分支状态，但无法自动化。
流程如下：
git checkout main && git merge --no-commit --no-ff feature/login-
git rm --cached config/database.yml（仅从暂存区移除，保留工作区原文件） - 如有多个文件，重复上一步；运行
git status确认这些文件显示为 “deleted from index” git commit -m "Merge feature/login, skip config/database.yml"
⚠️ 风险点：若误用 git checkout HEAD -- config/database.yml，会丢弃本地未提交修改；git rm --cached 更安全，因为它不碰工作区。
为什么 merge=ours 在某些情况下“失效”
这不是 Bug，是 Git 合并逻辑本身的设计限制。常见误判场景：
-
main分支从未提交过application.properties，而feature分支新增并提交了它 → 合并时该文件必然进入main，merge=ours不触发（因为不存在三方基础版本） -
main上该文件是空的，feature改写了全部内容 → Git 认为这是“新增文件”，而非“修改”，同样绕过策略 -
.gitattributes在feature分支存在，但未同步到main→ 合并时main的 Git 进程读不到策略定义
真正可靠的前置条件只有一个：目标分支（接收方）必须已有该文件的提交记录，且该记录与源分支的修改构成可比对的三方基础。否则，任何策略都只是摆设。
