首页/开发/Git 与协作速查/git merge -s ours 记录合并但不取内容
合并变基与冲突71 条

git merge -s ours 记录合并但不取内容

生成一个合并提交、但结果树保持当前分支不变,用来「宣告某分支已被吸收」;旧分支的内容不会进入主干。

Git 与协作速查开发更新于 2026-10-13

只记关系不取内容

生成一个合并提交,但结果内容保持当前分支不变,用来宣告某个分支已经被吸收。典型用途是让历史图保持连续、避免旧分支长期悬挂,同时明确这些内容不会进入主干。

基本信息

用途建立合并关系而忽略对方的内容
语法在当前分支上合并目标分支并指定该策略
结果历史图连续,文件内容保持不变
适用前提已确认对方分支的内容作废,或已通过其他提交并入
易混选项想保留对方内容时应改用其他合并方式

典型使用场景

  • 宣告已废弃的功能分支被吸收
  • 避免历史图里长期悬挂无人维护的分支
  • 让分支清理与统计工具认为该分支已经合并
  • 处理被替代实现取代的旧分支
  • 保持主干历史可视化的连贯性

常用示例

常用示例
git switch main
git merge -s ours legacy/old-api         # 建立合并关系,内容保持不变
git log --oneline --graph -5             # 查看历史图是否连续
git diff HEAD^ HEAD --stat               # 确认没有带入文件改动
git branch -d legacy/old-api             # 确认无误后删除本地分支

做法对比

做法内容是否带入历史表现
指定该策略合并不带入多一个合并提交,历史连续
普通合并带入内容与历史都并入
干脆不合并不带入旧分支在历史图中孤立悬挂
它建立的是历史关系而不是内容合并:动手前要确认对方分支的内容确实不需要,或者已经通过其他提交并入。
对方提交在历史图中会被画成已合并,之后在其基础上重新合并不会带入这些改动,容易造成「改了却没生效」的困惑。
清理长期无人维护的分支时用它可以把历史图收干净,同时保留「这个分支存在过」的记录。
如果只是想保留对方内容又不想产生合并提交,应改用压缩或变基方案,思路不能混用。

易错点

  • 误用之后他人以为改动已包含,实际文件未变,形成「改了却没生效」的排查事故
  • 把它当作通用合并方式使用,真正的改动被静默丢弃
  • 用完后没有说明原因,后来者看到合并提交却找不到对应代码,只能反复翻历史
  • 与压缩方案混用,分支被标记为已合并但内容只到一半,状态难以判断

数据来源与参考

  • Git 官方文档:git-merge(ours 策略)
​‌‌​​‌​​​‌‌​‌‌‌‌​‌‌​​​‌‌​‌‌‌​​‌‌​​‌​‌‌‌​​‌‌‌​​​‌​‌‌​‌​​‌​‌‌‌​​​‌​‌‌​‌​​‌​‌‌​​​‌‌​‌‌‌​‌​​​‌‌​‌‌‌‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌