git checkout --ours 和 --theirs 的含义取决于操作类型：merge 中 --ours 指当前分支（head），--theirs 指被合并分支；rebase 中二者角色翻转，--ours 指被变基的旧分支，--theirs 指目标基底分支，这是高频踩坑点。
git checkout --ours 和 git checkout --theirs 的真实行为
这两个命令不是“选当前分支”或“选目标分支”这么直白，它们的含义取决于你正在执行的操作类型。在 git merge 中：--ours 指的是你当前所在的分支（即 HEAD），--theirs 指的是你正试图合并进来的那个分支；但在 git rebase 中，角色完全翻转：--ours 反而指向被变基的分支（即原始提交），--theirs 指向目标基底分支——这是最容易踩坑的地方。
常见错误现象：在 rebase 过程中误用 git checkout --theirs file.js，结果却保留了自己原本的代码，以为“选了对方”，实际选的是旧版本。
- 判断当前上下文：运行
git status，看到 “rebase in progress” 就是 rebase 场景，“merging” 才是 merge 场景 - 不确定时，先用
git diff --ours和git diff --theirs分别预览两个版本内容，再决定是否覆盖 - 永远不要在未确认前对多个文件批量执行
--ours或--theirs，尤其当文件涉及配置、权限或二进制资源时
git merge -s ours 与 git checkout --ours 的本质区别
git merge -s ours 是一种**合并策略**，它会创建一个新提交，但该提交的内容完全来自当前分支，**彻底丢弃所有被合并分支的变更**，只保留合并记录；而 git checkout --ours 是一种**冲突解决动作**，仅作用于已发生冲突的单个文件，不改变其他未冲突文件的状态，也不影响合并提交的结构。
使用场景差异明显：前者适合“合并一个废弃分支但需保留历史痕迹”，比如清理实验性 feature 分支；后者适合“某个配置文件在两边都改了但必须以本地为准”。
-
git merge -s ours feature-legacy后，git log仍能看到feature-legacy的提交，但工作区代码毫无变化 -
git checkout --ours package.json只解决这一个文件的冲突，其余冲突文件仍需单独处理 - 注意：
-s ours策略下，即使被合并分支有新增文件，这些文件也不会出现在最终工作区里
如何安全地批量应用 --ours 或 --theirs
手动逐个文件执行 git checkout --ours 效率低且易漏，但直接写 shell 脚本批量操作又风险极高。更稳妥的做法是结合 git status --porcelain 和条件过滤。
GitHub 仓库备份技能 - 将 OpenClaw 工作空间自动或手动备份至 GitHub 私有仓库。支持自动定时备份和手动交互式配置，引导完成 Token 配置、仓库创建、首次备份及定时任务设置。用途：(1) 首次设置 (2) 日常备份。
例如，只想对所有冲突中的 JSON 配置文件统一保留本地版本：
git status --porcelain | awk '$1 == "UU" {print $2}' | grep '\.json$' | xargs -r git checkout --ours
这个命令链的关键点在于：UU 表示 unmerged，即明确处于冲突状态的文件；xargs -r 避免空输入时报错；grep 限制范围防止误操作。
- 永远在执行前加
echo预览将要操作的文件列表，比如把xargs -r git checkout --ours换成xargs -r echo - 不要用通配符如
*.js直接匹配，因为git checkout --ours不支持 glob，必须传具体路径 - 如果项目中有大量二进制文件（如图片、PDF），它们也会被标记为
UU，但--ours/--theirs对它们无效，需单独用git restore --ours（Git 2.23+）或手动处理
合并冲突时 --ours/--theirs 的兼容性陷阱
这两个选项在 Git 1.7.3+ 就已存在，但早期版本（尤其是 RHEL/CentOS 自带的 Git 1.7.1）不支持 --ours 作为 checkout 的参数，会报错 error: unknown option `ours'。此时只能退回到手动编辑或使用 git show :1:file（BASE）、git show :2:file（OURS）、git show :3:file（THEIRS）提取内容。
另一个隐形坑是 Windows 环境下的换行符干扰：当冲突文件本身包含 CRLF，而 Git 配置了 core.autocrlf=true，--ours 可能意外引入换行差异，导致后续 diff 看起来像“整文件变更”，其实只是 EOL。
- 检查 Git 版本：
git --version，低于 2.0 的建议升级 - 查看换行配置：
git config core.autocrlf，若为true，可在冲突解决后运行git add --renormalize .统一处理 - CI/CD 流水线中慎用
--ours/--theirs，某些 Git 实现（如 JGit）行为不一致，最好改用明确的git restore或脚本化 patch 应用
git status 和 git config，比背命令有用得多。
