Git合并冲突仅发生在三路合并中，即当前分支与待合并分支均相对于共同祖先修改了同一行或重叠区域时；快进合并不触发冲突，解决需手动编辑标记、删去并git add确认。
Git合并冲突不是“文件被改了就报错”，而是明确发生在「同一文件的同一行（或重叠行范围）被两个分支各自修改，且 Git 无法判断该保留哪一份」时。
冲突只在三路合并中出现
快进合并（git merge 时目标分支没动过）根本不会触发冲突——因为没有“三方比较”的必要。只有当 Git 找到共同祖先、并发现当前分支和待合并分支都相对于该祖先做了修改，才会进入三路合并流程，此时才可能冲突。
- 共同祖先 commit 是关键参考点，不是 HEAD 或最新提交
- Git 比较的是「祖先 vs 当前分支」和「祖先 vs 待合并分支」两组差异，不是直接比两个分支的 HEAD
- 如果两处修改落在文件不同区域（比如 A 改第5行、B 改第15行），Git 自动合并，不标记冲突
和 <code>>>>>>> feature/login 是什么
这些标记不是错误，是 Git 插入的“人工决策提示符”。HEAD 指向你当前所在分支的最新提交内容，feature/login 是你正试图合并进来的那个分支的最新提交内容。中间的 ======= 是分隔线。
OpenClaw 技能 — 给定一个 GitHub 仓库 URL，自动解析出 owner/repo 名称，发现其中的 YAML/properties 配置文件及其配对的中文字段说明；在 `workspace/{repo}/` 目录下按同步日期（格式为 `YYYY-MM-DD`）创建时间戳子目录；写入 `.openclaw-config-state.json` 状态文件。每次用户提问前，先比对远程仓库当前 ref（如 `main` 或 `master`）的最新提交 SHA 与本地状态文件中记录的 SHA：
- 标记只出现在冲突文件里，其他文件照常合并
- 必须手动删掉这三行标记，并保留最终需要的代码逻辑（可混合、可取舍）
- 保留标记提交会导致运行时语法错误，Git 不会校验内容是否合法，只认你删了标记并
git add过
解决后必须 git add，不能跳过
很多人解决完冲突直接 git commit，结果报错 “no changes added to commit”。这是因为 Git 把冲突状态视为“未暂存”，即使文件已编辑，也必须显式 git add 文件名 才算确认解决。
-
git status会明确列出 “both modified” 的文件，这是唯一可靠的状态信号 - 用
git add -u可批量暂存所有已修改文件，但要小心误暂存非冲突改动 - 执行
git merge --continue前，Git 会检查是否有未add的冲突文件，有则拒绝继续
--no-ff 不影响冲突发生与否，只影响提交图谱
加不加 --no-ff 对冲突判定毫无影响。它只决定：当快进可行时，是否强制生成一个合并提交（commit）。
- 冲突一定发生在合并过程中，和是否产生合并提交无关
- 不加
--no-ff时，若发生冲突，Git 仍会创建合并提交（因为无法快进） - 加了
--no-ff后，即使能快进，也会多一个空合并提交，纯粹为保留分支脉络
真正容易被忽略的是：冲突解决不是“选A或B”，而是“构造C”——你写出的最终内容，可能既不完全来自 HEAD，也不完全来自 feature/login，而是融合后的第三种状态。Git 不参与逻辑判断，只提供上下文和机制。
