冲突是git暂停合并等待人工决策，需用git status定位、git diff分析差异，手动编辑或mergetool解决，切勿盲目重置；解决后git add并提交，出错优先revert而非force push。
看到 CONFLICT (content) 提示时，先别删文件
Git 检测到同一段代码在两个分支里被不同修改，就会停在合并中途，标记冲突区域。这不是错误，是 Git 在等你人工判断——它不会擅自覆盖或丢弃任何一方的改动。
常见错误现象：git merge 后没报错但工作区“卡住”，git status 显示 Unmerged paths，文件里出现 和 <code>>>>>>> branch-name 这类分隔符。
- 不要直接
git reset --hard或删掉冲突文件重来——你会丢失当前分支的修改 - 先用
git status看哪些文件冲突，再用git diff查看具体差异（git diff --ours/git diff --theirs可分别看当前分支和目标分支的版本） - 编辑器里打开冲突文件，手动删掉所有
、<code>=======、>>>>>>行，只保留最终要保留的逻辑
git checkout --ours 和 git checkout --theirs 的真实作用场景
这两个命令不是“选 A 或选 B”那么简单，它们的行为取决于当前操作上下文：在 merge 中，--ours 指的是当前所在分支（HEAD），--theirs 指的是你正在合并进来的那个分支；但在 rebase 中，含义会反过来——容易踩坑。
alfred-github-backup
下载
GitHub 仓库备份技能 - 将 OpenClaw 工作空间自动或手动备份至 GitHub 私有仓库。支持自动定时备份和手动交互式配置，引导完成 Token 配置、仓库创建、首次备份及定时任务设置。用途：(1) 首次设置 (2) 日常备份。
- 仅当冲突逻辑完全一边倒（比如对方改了注释，你改了核心逻辑），才考虑用
git checkout --ours <file></file>快速采纳当前分支版本 - 执行后记得
git add <file></file>标记为已解决，否则 Git 仍认为冲突未处理 - 不建议在多处冲突时批量使用——容易漏掉真正需要人工比对的关键逻辑
- 注意：这些命令只影响工作区和暂存区，不影响 HEAD 指针，也不是撤销 merge 的方式
用 git mergetool 而不是硬扛文本对比
纯靠眼睛扫 块很容易看串行、漏条件、误删空行——尤其在 JSON、YAML 或缩进敏感的 Python 文件里。
- 先配一个靠谱的工具：
git config --global merge.tool vimdiff（或vscode、meld），然后运行git mergetool - 工具会把三方内容并排显示：LOCAL（你当前分支）、BASE（共同祖先）、REMOTE（对方分支），中间是 MERGED（你编辑的输出）
- 保存退出后，工具自动帮你
git add，不用再手动确认每个文件 - 如果某次合并里只有 1–2 个文件冲突，手修更快；超过 5 个，
mergetool节省的时间远超配置成本
合并后发现逻辑错了？回退比重做更安全
冲突解决了、git commit 也提交了，结果测试崩了——这时候最危险的操作是直接 git push --force 覆盖远程历史，尤其在多人协作分支上。
- 优先用
git revert -m 1 <merge-commit-hash></merge-commit-hash>生成一个反向提交，干净、可追溯、不破坏他人本地历史 -
-m 1参数必须加，否则revert会当成普通提交处理，无法正确撤销合并引入的变更 - 如果还没推送到远程，可以用
git reset --hard HEAD~1回退，但务必确认没人基于这个 merge 提交过新工作 - 别忘了检查 CI 是否已触发构建——有些系统会在 merge commit 创建后立刻跑测试，回退后可能需要手动取消队列
======= 行靠谱得多。
