冲突不是“出错了”，而是 Git 提醒你本地和远程对同一段代码做了不同修改，必须由人决定最终保留哪部分；跳过同步、硬 push、merge 代替 rebase 是引发混乱的三大主因。
直接说结论：冲突不是“出错了”，而是 Git 在提醒你——本地和远程对同一段代码做了不同修改，必须由人来决定最终保留哪部分。跳过同步、硬 push、merge 代替 rebase，是引发混乱的三大主因。
为什么 git pull 后还报 conflict？
因为 git pull 本质是 git fetch + git merge，它会把远程新提交“合并”进你当前分支，一旦双方改了同一行，Git 就无法自动判断取舍，只能停在 MERGING 状态等你处理。
- 常见错误现象：执行
git pull origin main后提示CONFLICT (content)，文件里出现<<<<<< HEAD和=======分隔块 - 真实原因：不是远程或你写错了，而是你们俩都动了
src/utils.js的第 42 行，Git 拒绝替你做决定 - 关键区别：
git fetch只下载远程信息，不碰你本地代码；git pull会立刻尝试合并——所以高频协作中，建议先git fetch查看差异，再决定用rebase还是merge
rebase 比 merge 更适合日常协作吗？
是的，尤其当你在功能分支上开发时。git rebase 把你的提交“重放”到目标分支最新版之后，历史是线性的，不会插入无意义的 Merge branch 'main' into feature/login 提交。
- 适用场景：你在
feature/user-profile上写了 3 个 commit，期间main被同事更新了 2 次，你想让自己的改动基于最新main再提交 - 实操步骤：
git checkout feature/user-profile→git fetch origin→git rebase origin/main - 注意坑点：如果 rebase 过程中遇到冲突，解决后要
git add .，再git rebase --continue；千万别git commit，否则会生成冗余提交 - 性能影响：rebase 会重写提交哈希值，因此不能对已推送的公共分支使用（比如
main或已共享的dev）
本地有未提交修改时怎么安全拉取远程更新？
别硬 git pull，用 git stash 临时存起来，等同步完再取回，避免工作区被污染。
- 典型场景：你正在改
package.json，但需要立刻拉main上的 hotfix - 正确流程：
git stash push -m "wip: update deps"→git checkout main→git pull origin main→git stash pop - 风险提示：
git stash pop可能再次触发冲突，尤其是你 stash 的内容和刚 pull 下来的有重叠；此时需手动编辑、git add、再git stash drop清理栈 - 替代方案：如果只是少量修改，
git stash -k（keep-index）可保留暂存区状态，更精准控制哪些内容进 stash
push 被拒后强行用 --force 会怎样？
会覆盖远程分支历史，可能让队友的本地分支彻底失效，除非你明确知道自己在重写谁的历史，否则禁用 --force。
- 错误现象：
! [rejected] main -> main (non-fast-forward)，然后有人输git push --force origin main - 实际后果：远程
main上所有其他人还没拉取的新提交都会丢失，他们的git pull会失败，必须手动git reset --hard origin/main强制对齐——这等于强制所有人丢弃本地未推送的改动 - 安全替代：
git push --force-with-lease，它会在推送前检查远程引用是否和你本地记录的一致，防止误覆盖他人新提交 - 真正该 force 的唯一场景：你刚 rebase 完自己的私有功能分支，且确认没人基于它开发，此时
git push --force-with-lease origin feature/x是合理操作
最易被忽略的一点：冲突解决后，很多人只 git add 文件就以为完事了，但忘了 git rebase --continue 或 git merge --continue ——Git 会卡在中间状态，下次 git status 仍显示 “You are currently rebasing/merging”，不继续就推不出去。
