conflict (content) 是 git 暂停合并等待手动解决的正常状态，需删除冲突标记、保留正确逻辑、执行 git add，再提交；可用 --abort 安全回退，ide 工具可辅助但不能替代逻辑判断。

看到 CONFLICT (content) 别慌，这是 Git 在等你拍板

这不是错误，也不是仓库损坏。Git 发现两个分支在同一文件的同一段落做了不同修改，它不敢自动选一个——怕删掉你真正要的逻辑。此时终端会打印类似 CONFLICT (content): Merge conflict in src/utils.js，git status 会把该文件标为 both modified。关键点在于：Git 已暂停合并流程，工作区和暂存区处于“半合并”状态，但还没生成任何提交。

手动编辑冲突文件时，必须删掉三行标记并保留逻辑

打开冲突文件，你会看到类似这样的结构：

>>>>>> feature/date-format

这三行（、<code>=======、>>>>>> feature/date-format）是纯标记，不是代码，必须全部删除。只保留你最终要的实现，比如用 moment 版本，就删掉上面那段和三行标记，只留第二段函数定义。不要留空行、不要漏删、不要只删两行。

batch-git-url-replace

批量替换指定目录下所有 Git 仓库的远程地址（remote URL）。 当用户需要将 Git 仓库从一个服务器迁移到另一个服务器时使用。 触发词：git remote 替换、git url 批量修改、git 仓库迁移、更换 git 地址、批量修改 remote url。

下载

• 删完保存后，必须立刻执行 git add src/utils.js —— 否则 Git 不认为冲突已解决
• 如果改错或想重来，可用 git checkout --ours src/utils.js（保留当前分支版本）或 git checkout --theirs src/utils.js（保留待合并分支版本）快速回退
• 别在未 git add 前就 git commit，否则会把冲突标记一起提交进历史

git merge --abort 和 git rebase --abort 是你的安全绳

merge 或 rebase 过程中一旦卡住，又不想继续解决，这两个命令能干净回退到操作前状态。它们不会丢你工作区的修改，也不会影响已提交的历史。

• git merge --abort 适用于 git merge 或 git pull 卡在冲突时
• git rebase --abort 适用于 git rebase 过程中某次 commit 冲突无法处理
• 注意：git rebase --skip 会跳过当前 commit，可能丢改动，慎用；git reset --hard 会丢未提交变更，不是 abort 的替代品

IDE 或 GUI 工具能省力，但不能绕过“理解谁改了什么”

VS Code 内置合并编辑器、GitKraken 的三栏对比、IDEA 的 Merge… 窗口，都能高亮显示 ours/theirs/base 三个版本。它们帮你省去手动定位标记的步骤，但最终决定哪段逻辑该留、哪段该删、要不要融合两者的责任仍在你。

容易被忽略的一点是：冲突往往不止一行。一个函数体被两边同时重写，或配置对象里几个 key 被不同分支改了值，这种“语义冲突”不会被工具自动识别，必须你通读上下文才能判断。标记删得再干净，逻辑没理清，照样埋雷。