git merge -x theirs 表示在合并时自动采用被合并分支（theirs）的代码版本，适用于明确要完全保留目标分支内容的场景；其原理是冲突时弃当前分支修改、取对方分支变更，但仅对文本冲突生效，且需手动提交。
git merge 时用 -X theirs 快速保留目标分支代码
当执行 git merge feature 发生冲突，而你明确想「全部采用目标分支（即当前所在分支）的版本」，不要手动删标记——git merge -X theirs 是最直接的方案。注意：这里的 theirs 指的是「被合并进来的那个分支」，不是你当前所在的分支，这点极易搞反。
常见错误是以为 theirs = 当前分支，结果执行后反而保留了 feature 分支的代码，把本地修改全丢了。本质是 Git 在 merge 场景下把「当前分支」叫 ours，把「要合并进来的分支」叫 theirs —— 和 git checkout --ours 这类命令里的语义一致，但和日常语言相反。
-
git checkout feature && git merge -X theirs main：当前在feature，要把main合进来 →theirs = main→ 最终保留main的内容 -
git checkout main && git merge -X theirs feature：当前在main，要把feature合进来 →theirs = feature→ 最终保留feature的内容 - 该策略只对「文本冲突」生效，不处理文件增删、重命名等类型冲突
- 执行后仍需
git add . && git commit完成合并，Git 不会自动提交
手动编辑冲突文件时怎么安全保留目标分支代码
如果已经进入冲突状态，且不想用 -X 策略（比如只想保留部分文件的目标版本），打开冲突文件后，看清三段式标记位置：
Conventional Commits v1.0.0 分支、工作树命名及提交信息规范，适用于 GitHub 与 GitLab 项目，用于创建分支和命名工作树等场景。
和 <code>======= 之间是你当前分支的代码，======= 到 >>>>>> feature/xxx 之间是被合并分支的代码。所谓「保留目标分支代码」，就是删掉 及其后面的内容，包括整行 <code>=======，只留下 >>>>>> feature/xxx 后面那部分，再删掉 >>>>>> feature/xxx 这行本身。
- 别只删
和 <code>=======，忘了删>>>>>>行，否则提交时 Git 仍报错「conflict markers still present」 - 如果文件里有多处冲突块，每一处都要单独处理，不能只改开头
- 改完后用
git status确认该文件状态变成modified而非unmerged - 推荐用 VS Code 或 IntelliJ 打开，它们会高亮冲突区域并提供「Accept Current Change / Accept Incoming Change」按钮，点「Accept Incoming Change」就等价于保留目标分支代码
为什么 git checkout --theirs 在 merge 中不适用
git checkout --theirs <file></file> 这个命令只在 git checkout 切换分支发生冲突时有效，比如 git checkout main 时提示冲突，此时可以用它恢复暂存区中 theirs 版本。但它在 git merge 过程中无效——merge 状态下暂存区结构不同，--theirs 会报错 error: path 'xxx' does not have our version。
- merge 中真正可用的是
git checkout --ours <file></file>和git checkout --theirs <file></file>，但必须配合-m（merge）参数：git checkout -m --theirs <file></file> - 更稳妥的做法是先
git show :2:<file></file>（ours）、git show :3:<file></file>（theirs）确认内容，再用git restore --source=HEAD --staged --worktree <file></file>或直接覆盖 - 多数人卡在这一步，是因为查文档时没注意上下文：checkout 的
--theirs和 merge 的--theirs是两个不同机制
rebase 场景下保留目标分支代码的逻辑完全不同
如果是 git rebase main（把当前分支变基到 main 上），冲突时的 theirs 指的是 main，但操作方式不是 -X theirs —— rebase 不支持 -X 参数。此时只能手动解决，或用 git rebase --skip（跳过当前提交，风险极高）或 git rebase --abort 回退。
- rebase 中想批量保留
main的修改，唯一安全做法是：先git stash保存当前改动，git rebase main完成后再git stash pop，然后手动合并 stash 内容到新基线 - 不要依赖
git checkout --theirs在 rebase 中“一键覆盖”，它在 rebase 的暂存区语义下行为不稳定 - rebase 本质是重放提交，没有“合并提交”概念，所以所有冲突都按单个提交粒度处理，无法像 merge 那样全局指定策略
、<code>=======、>>>>>> 全部清除干净，且 git status 中对应文件不再显示为 Unmerged paths。这是最容易被忽略的收尾动作。
