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/*),否则策略不生效。
审计 GitHub Actions 工作流文件的密钥泄露风险,例如 pull_request_target 密钥使用、密钥回显命令及未固定版本的 Action 密钥传递。
- 路径必须精确匹配:用
/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 进程读不到策略定义
真正可靠的前置条件只有一个:目标分支(接收方)必须已有该文件的提交记录,且该记录与源分支的修改构成可比对的三方基础。否则,任何策略都只是摆设。

















