conflict (content) 不是错误，而是 git 主动暂停合并待人工决策；需用 git status 定位冲突文件，手动编辑删去 > branch-name 标记并融合逻辑，再 git add 标记解决，最后 git commit 完成合并。
git merge 时提示 CONFLICT (content) 怎么办
这不是错误，而是 Git 在告诉你：同一文件的同一段代码，两个分支改出了不同结果，它没法自动选一个。你得手动决定保留哪边、怎么合并。
常见现象：CONFLICT (content): Merge conflict in src/LoginController.java 出现在终端，git status 显示该文件状态为 both modified。
- 别直接
git commit—— 此时 Git 还没认可你“解决完了”，强行提交会把冲突标记一起塞进历史 - 打开文件，你会看到三段标记：
（当前分支内容）、<code>=======（分隔线）、>>>>>> feature/login（要合并进来的分支内容） - 删掉这三行标记，只留你最终要的代码逻辑，保存文件
- 执行
git add src/LoginController.java—— 这步必须做，否则 Git 不认为冲突已解决 - 再
git commit -m "merge: resolve conflict in LoginController"
git pull origin main 失败后怎么续
git pull origin main 其实是 git fetch + git merge 的组合操作。失败时，Git 已完成 fetch，但 merge 卡在冲突上 —— 所以你本地工作区和暂存区已处于“半合并”状态。
关键点：此时 git status 仍能列出冲突文件，且 HEAD 指向 main 分支，但提交尚未完成。
- 先确认哪些文件冲突：
git status，重点关注Unmerged paths区域 - 逐个编辑、清理冲突标记、保存
- 每解决一个，立刻
git add <file></file>，别攒着一起加 - 全部
add完后，git commit即可完成 pull 流程 - 如果想放弃这次拉取：
git merge --abort，回到拉取前状态
rebase 过程中遇到冲突怎么继续
rebase 是把当前分支的提交“重放”到目标分支顶端，每次重放一个 commit。冲突发生时，它停在那个出问题的 commit 上，而不是整个流程中断。
和 merge 不同：rebase 不会产生 merge commit，历史更线性，但也更“脆弱”——一旦出错，容易丢失上下文。
- 解决完冲突文件后，
git add <file></file>标记为已处理 - 运行
git rebase --continue继续重放后续 commit - 如果当前这个 commit 实在没法干净合并，可用
git rebase --skip跳过它（慎用！可能丢改动） - 想彻底退出：
git rebase --abort，所有 rebase 操作回滚，回到 rebase 前状态 - 注意：rebase 后的 commit hash 全变了，已推送到远程的分支不要轻易 rebase，尤其多人共用时
冲突解决后编译/测试被忽略的后果
很多开发者删完
比如两个分支都改了同一个 if 条件，你手动合并后可能漏掉某个 else 分支，或者参数顺序错位 —— 编译器不报错，但运行时崩溃。
- 冲突解决后，至少执行一次本地构建（
mvn compile或npm run build） - 跑一遍相关单元测试，尤其是涉及冲突文件的 test case
- 如果项目有 CI，别跳过 PR/MR 的自动检查，等它通过再合入
- 最隐蔽的坑：二进制文件（如图片、Excel）冲突无法用文本标记识别，
git status只显示both modified，需人工比对或按需用git checkout --ours/git checkout --theirs强制选一边
