git merge后终端无提示不等于失败，快进合并会静默完成；成功标志是输出“Already up to date”或“Merge made by the 'ort' strategy”，否则需用git status检查Unmerged paths并手动解决冲突。
git merge 后卡住没报错，其实是合并成功了
很多人执行 git merge feature 后终端没输出、没报错、也没提示，就以为命令“没反应”或“失败了”。其实 Git 已静默完成快进（fast-forward）合并——只要当前分支历史是目标分支的直接上游，且无冲突，它就只移动指针，不生成新提交。
判断是否真成功，别靠感觉，看终端最后一行输出：Already up to date 或 Merge made by the 'ort' strategy 才算落地。如果没看到这两句，大概率是卡在冲突里了，此时 git status 一定显示 Unmerged paths。
常见误操作：
- 没确认当前分支就开干：比如本想把
feature合入main，却还在feature分支上执行git merge main，结果反向合并 - 合并前没
git pull origin main：本地main落后远程，导致本可避免的冲突 - 依赖 IDE 状态栏判断冲突：VS Code 有时不刷新“冲突文件”标记，得信
git status
冲突文件里出现 <<<<< HEAD 是正常现象，不是 bug
Git 插入的 <<<<< HEAD、=======、>>>>> feature 这三行，是它主动暂停合并的信号，不是错误。它的意思是：“这段代码，你当前分支（HEAD）和待合入分支（feature）都改过，我没法替你决定留谁。”
解决逻辑不是“删掉标记”，而是“删掉标记 + 保留/融合实际要生效的代码”。例如：
if (user.role === 'admin') {
<<<<< HEAD
showDashboard();
=======
renderAdminPanel();
>>>>> feature
}
你得根据业务判断：是保留 showDashboard()，还是改成 renderAdminPanel()，或者加个兼容逻辑，再删掉那三行。
容易踩的坑：
使用约定式提交（Conventional Commits）从 Git 历史记录中生成结构化变更日志，支持多种格式、AI 增强型描述以及可自定义的范围……
- 用编辑器“全部替换”删掉
<<<<<—— 可能误删变量名里带这个子串的合法代码 - 只删标记、不检查语法：比如删完漏了花括号或分号，后续
git commit虽能过，但运行时报错 - 在 Python/YAML/JSON 文件里硬扛文本对比：缩进、换行、逗号位置稍错就失效，建议直接上
git mergetool
git checkout --ours 和 git checkout --theirs 容易搞反含义
这两个命令在 merge 场景下，--ours 指的是你当前所在的分支（比如 main），--theirs 指的是你正试图合入的那个分支（比如 feature）。但到了 rebase 场景，含义完全翻转——这是最常被踩的语义坑。
它们适合的场景很窄：整份文件你明确只想用某一方的全部内容，不想逐行比对。比如你确认 feature 分支里的 package.json 版本更新更准，就直接：
git checkout --theirs package.json git add package.json
但要注意：
- 它们只影响工作区和暂存区，不会改变
HEAD，也不是中止合并的方式 - 别批量对一堆文件执行
--ours—— 很可能把需要人工融合的关键逻辑直接覆盖掉 - 执行后仍需
git add，否则 Git 还认为这文件处于未合并状态
解决完冲突必须 git add，否则 git commit 一定失败
这是最常被跳过的一步。删完冲突标记、保存文件、甚至 git status 看着“干净”了，一执行 git commit 却报错：fatal: cannot do a partial commit during a merge。
原因很简单：Git 把冲突文件标记为“未合并（unmerged）”，只有你显式执行 git add <file>，它才把该文件从“未合并路径”移出、放进暂存区。没这步，git commit 就拒绝干活。
实操建议：
- 一个一个
git add <file>更安全，避免误加临时改动 - 用
git status -s | grep "^UU"快速列出所有冲突项，防止漏文件 - 别用
git add .图省事——它会把未跟踪的新文件也加进来，可能污染本次合并 - 如果改完发现逻辑不对，立刻
git merge --abort，它只在git status显示merging时有效，且不丢任何已有修改
真正麻烦的从来不是冲突本身，而是有人删了标记就去 git push，结果别人拉下来发现文件里还残留着 >>>>> —— 那不是 Git 的问题，是流程断在了 git add 这一步。
