冲突需手动解决：先用git status查看冲突文件，编辑删除冲突标记（<<<<<<< HEAD到>>>>>>> origin/main）并保留正确代码，再git add和git commit（或git merge --continue）。
git pull 报错 “CONFLICT (content): Merge conflict in xxx” 怎么办
冲突不是错误，是 Git 在告诉你：两边都改了同一段代码，它没法自动猜你想留哪版。别急着 git reset --hard 或删仓库重来——90% 的情况能安全手动解决。
关键动作就三步：git status 看哪些文件冲突 → 编辑文件删掉 Git 标记的冲突块（<<<<< HEAD 到 >>>>> origin/main）→ git add <file> 标记已解决 → git commit（或 git merge --continue）。
- 冲突标记里
HEAD是你本地修改，origin/main（或类似分支名）是远程要拉下来的版本 - 别只删标记行，要保留逻辑正确的代码，删掉整段冲突块里你不要的那一半
- 如果改得乱了，
git checkout --ours <file>用本地版覆盖，git checkout --theirs <file>用远程版覆盖（注意：这两个命令会丢弃另一方改动，慎用）
vscode 里点“Accept Current Change”反而更危险？
VS Code 内置的合并编辑器默认按钮很友好，但“Accept Current Change”和“Accept Incoming Change”容易看反——它说的“Current”是你当前分支（HEAD），不是“你现在正看着的这段代码”。一不小心就点了反的，把刚写的逻辑全丢了。
- 务必先看清顶部状态栏显示的是
HEAD还是origin/main - 推荐关掉自动合并提示：设置里搜
git.mergeEditor，设为false，改用纯文本编辑，眼见为实 - 冲突文件右上角有三个小圆点图标，点开能看到“Compare Changes”，比按钮更可靠
rebase 模式下 pull 冲突和 merge 模式有什么区别
git pull --rebase 不是“避免冲突”，而是把你的本地提交暂时拿掉，先应用远程更新，再把你提交“重放”上去。冲突位置可能变：原来在 merge 提交里出现的冲突，现在出现在你某次本地 commit 的 patch 里。
- 冲突时你会看到类似
error: could not apply abc123... fix login bug，说明这个 commit 应用失败了 - 解决后不用
git commit，而是git rebase --continue - 如果中间想放弃整个 rebase，
git rebase --abort最安全，不会影响工作区 - 团队协作中，除非明确约定用 rebase 流程，否则普通
git pull（即 merge）更不易出错
冲突解决了，push 却被拒绝：failed to push some refs
这不是冲突没解完，是别人又 push 了新提交——你解决完冲突、commit 后，远程分支已经变了。Git 拒绝非快进推送（non-fast-forward），防止覆盖他人工作。
- 立刻
git fetch拉最新状态，再git rebase origin/main（或git merge origin/main） - 如果用了 rebase，注意：你本地 commit 的 hash 全变了，之前分享过的 commit id 失效
- 如果多人共用一个功能分支，且你已 force push 过，务必在群内同步：“我刚刚 rebase 并 force push 了 feature/login，请其他人先
git fetch && git reset --hard origin/feature/login”
最常被跳过的动作是 git fetch 后没确认远程分支是否真有新提交——直接 git push 失败才回头查，其实 git ls-remote origin main 能提前看远端最新 commit id。
