<<<<<<< HEADif (failed) { retry(); }=======if (failed) { clearPassword(); }>>>>>>> feature
标记还在
同一段两种改法。删掉标记之前，合并提交不会生成。
先认出文件里的三段标记，再决定留什么
下面就是冲突打开后的 login.ts。默认标记还在；只留一边会把丢失写在代码行上；合并双方后，标记消失、两个意图都在。
第 0 步先打开：终端跑 git status，再打开标成 both modified 的文件。下面就是那份带标记的 login.ts。
原因：两边改了同一段。下一步：读三方再决定，或先看只留一边会丢掉什么。
知识点：标记是待处理证据
文件里刚走过的路，这里只给命名。
<<<<<<</=======/>>>>>>>标出 ours 和 theirs。- base 是共同祖先，用来判断两边各自加了什么。
- 目标是不丢任一方必要意图，不是尽快让标记消失。
- 删干净标记、git add、跑测试，才能继续合并。
什么时候用、怎么用
冲突来了再解决，不要预先猜。
- 信号：merge / rebase / 合 PR 时文件变成 both modified。
- 最短路径：
git status→ 逐 hunk 读三方 → 改完删标记 →git add→git merge --continue→ 跑测试。 - 不适用：二进制冲突用整份 ours/theirs，不要手改标记。
正反例：同一段冲突，只改一处取舍
只改变「有没有读双方意图」，结果完全不一样。
main 要重试，feature 要清密码，二者不矛盾。写进同一行，失败登录既重试又清字段。
标记没了就算「解决」。清密码丢了，用户失败后旧密码还留在框里。
快速自测
base 是 timeout = 5000，ours 改成 3000，theirs 改成 connectSpeed()。哪种解决最稳？
继续查证
术语的技术定义和行为以这些一手或权威资料为准。
下一步学
和本知识点经常一起出现的概念。