冲突标记不是错误，而是git主动暂停合并的提示；必须手动删除> branch-name这三行，仅保留最终业务代码，否则项目报错。
冲突标记不是错误，是 Git 主动暂停合并的提示；必须手动删掉 、<code>=======、>>>>>> branch-name 这三行，只留最终业务代码，否则项目会直接报错。
冲突文件里
这是 Git 插入的元信息，不是你写的代码。它表示“从这里开始是当前分支（HEAD 所在分支）的修改内容”。比如你在 main 分支上改了 utils.js 的第 12 行，执行 git merge feature/login 时触发冲突，那 后面紧跟着的就是你在 <code>main 上写的那行——不是“旧代码”，而是你本地当前分支的最新改动。
常见误解：以为 HEAD 指的是“原始版本”或“老代码”。其实它就是你 git checkout 切到的那个分支的最新提交内容。
======= 和 >>>>>>> branch-name 怎么理解
======= 是纯分隔符，无业务含义；>>>>>> feature/login 后面的内容，是你正要合并进来的那个分支（这里是 feature/login）在相同位置的修改。
关键点：
批量替换指定目录下所有 Git 仓库的远程地址（remote URL）。 当用户需要将 Git 仓库从一个服务器迁移到另一个服务器时使用。 触发词：git remote 替换、git url 批量修改、git 仓库迁移、更换 git 地址、批量修改 remote url。
- 这两段代码都是“有效修改”，不是一方对、一方错
- Git 不知道你要保留哪边，或者是否要合并逻辑（比如拼接两行、取交集、加条件判断）
- 标记本身必须整行删除，不能只删一半，也不能留空行代替
- 如果看到
>>>>>> 7f3a1b2这种 commit ID 形式，说明是git pull或git merge时没指定分支名，Git 用哈希代替了
删完标记后为什么 git add 必须做
Git 不靠“文件内容有没有标记”来判断冲突是否解决，而是靠索引（index）状态。即使你手动删光了所有冲突符号并保存了文件，只要没执行 git add <file></file>，Git 依然认为该文件处于 Unmerged 状态。
典型后果：
-
git status仍显示both modified -
git commit会失败，提示 “You have not concluded your merge (MERGE_HEAD exists)” - 强行
git commit -m "fix"会把残留的冲突标记一起提交进历史，后续所有人拉代码都会继承这个“带毒”的文件
所以 git add 是确认动作，不是可选步骤。
容易被忽略的边界情况
有些冲突看起来“删完就完了”，但实际埋了坑：
- 多个冲突区块共存于同一文件：必须逐个处理，漏掉一个
区块，<code>git add后git status仍会报冲突 - 空行或缩进差异被 Git 当作内容冲突：尤其在 JSON、YAML 配置文件中，看似只是多了一行空格，但 Git 会标出整块，需人工核对语义是否等价
- 文件权限变更 + 内容修改：Git 可能报
CONFLICT (mode)，此时标记不会出现，得用 <code>git ls-files -s查 inode 模式 - 合并后忘记跑测试：逻辑合并正确 ≠ 行为正确，比如两个分支都加了同名函数但参数不同，删完标记后可能引发运行时报错
最危险的不是看不懂标记，而是删得快、加得快、提交快，却没验证行为是否符合预期。
