git reset --hard origin/main 可强制丢弃本地所有未推送提交及工作区修改，使本地分支完全同步远程最新状态，操作不可逆，需提前备份。
git merge 时直接丢弃本地修改，用远程分支覆盖
想跳过手动编辑冲突文件、不保留任何本地改动，就用 git checkout --ours 或 git checkout --theirs 是错的——这两个命令只在 git merge 过程中临时生效，且语义容易反：--ours 指的是「当前分支」（你正站在的分支），--theirs 指的是「被合并进来的分支」。但当你执行 git pull origin main，它本质是 git fetch + git merge FETCH_HEAD，此时 --theirs 实际指向的是远程 main 的内容，也就是你要的“以远程为准”。
不过更稳妥、无歧义的做法是：先中止合并，再重置到远程状态。
- 运行
git merge --abort（如果已进入冲突状态） - 确认当前分支干净：
git status应显示 “nothing to commit, working tree clean” - 强制让本地分支和远程完全一致：
git reset --hard origin/main（把main替换为你实际要对齐的远程分支名） - 该操作会丢弃所有未推送的本地提交和工作区改动，不可逆
为什么不用 git checkout --theirs 单独处理冲突文件
单独对某个冲突文件执行 git checkout --theirs path/to/file.py 看似可行，但有三个现实问题：
- 它只解决单个文件，而一次
git pull可能触发十几个冲突文件，逐个敲命令效率低且易漏 - 如果该文件在本地有未暂存的修改（
git status显示为 modified 而非 unmerged），--theirs不起作用，反而报错 “pathspec 'xxx' did not match any files” - 它不处理 Git 认为“已解决”的部分（比如仅修改了行尾换行符），可能留下隐藏差异
pull 前就决定“以远程为准”，该怎么预防冲突
与其等冲突发生再擦屁股，不如在拉取阶段就明确策略。Git 本身不支持 pull 时全局指定 --theirs，但你可以组合命令实现等效效果：
- 先 fetch 远程最新状态：
git fetch origin - 再硬重置本地分支到远程对应位置：
git reset --hard origin/develop（假设你在develop分支） - 这个流程绕过了 merge 步骤，自然不会产生 conflict 标记，也避免了
git pull自动触发 merge 的不确定性 - 注意：这要求你本地没有需要保留的未推送提交；如果有，必须先
git stash或另存为临时分支
IDEA 里点 “Accept theirs” 为什么有时不生效
IntelliJ IDEA 的图形化冲突解决界面里，“Accept theirs” 按钮看似直接，但背后依赖 Git 的 index 状态。常见失效场景：
- 你手动编辑过冲突标记区域，但没点击右上角的 “Apply” —— IDEA 不会自动写入暂存区，
git status仍显示 unmerged - 文件编码或行尾符（CRLF/LF）不一致，导致 IDEA 误判“内容不同”，按钮灰掉或点击后内容未更新
- 项目启用了 Git 的
core.autocrlf，而本地设置与远程仓库不一致，造成 diff 误报冲突 - 真正保险的做法：关闭 IDEA 冲突窗口 → 在终端执行
git checkout --theirs -- path/to/file→git add path/to/file
最常被忽略的一点：reset --hard origin/xxx 这类操作，不会影响其他本地分支的提交历史，但会彻底清除当前分支上所有未推送到远端的提交。如果不确定，先 git branch backup-before-reset 备份一下再动手。
