git pull --rebase 不推荐日常使用，因其将 fetch 与 rebase 合为一步，跳过 git fetch 后校验远程更新（如 git log main..origin/main）、定位冲突来源、确认 origin 引用状态等关键检查点，易致调试困难、状态异常或重复提交。
增量代码更新不是“拉新代码”，而是“把你的改动安全地叠到最新主干上”——git fetch + git rebase 是最可控的方式，但直接 git pull --rebase 容易掩盖问题，不建议日常使用。
为什么不能只用 git pull --rebase
它把 fetch 和 rebase 合成一步，看似省事，实则跳过关键检查点：
- 你无法确认远程分支是否真被更新了（
git fetch后可执行git log origin/main..main对比） - 冲突发生时，你不知道是哪次本地提交触发的，调试成本陡增
- 如果远程已有他人推送，
git pull --rebase会静默覆盖你本地的origin/main引用，导致后续git status显示异常
git fetch 后该看什么才不算白 fetch
fetch 只下载对象和引用，不改任何本地分支。执行完必须立刻验证：
- 运行
git log --oneline main..origin/main：看到输出，说明主干有新提交；空输出，说明没更新 - 运行
git status：若提示 “Your branch is behind 'origin/main' by X commits”，说明本地main确实旧了 - 别只信
git branch -r：它显示的是你上次 fetch 时的远程状态，不是实时的
rebase 到底 rebase 谁？目标分支选错就全乱了
常见错误是把 git rebase origin/main 执行在 main 分支上——这会让 main 自己重放自己，产生重复提交。
正确姿势是：
- 你在功能分支（如
feat/login）上开发，想同步主干更新 → 切到该分支，执行git rebase origin/main - 你想把功能分支干净合并进主干 → 先切回
main，执行git merge --ff-only feat/login（前提是已用 rebase 同步过） - 若目标分支名不是
main（比如是dev），务必写全origin/dev，不要依赖本地dev分支是否最新
冲突了怎么知道该改哪几个文件？
rebase 冲突不是一次性全爆出来，而是按提交顺序逐个触发。每次卡住时：
- 运行
git status：只列出当前这个提交引发冲突的文件，不是全部 - 别急着
git add .：只git add你真正修改过的冲突文件，否则会把其他提交的改动也带进来 - 解决完后必须
git add <file>，再git rebase --continue；漏掉git add会导致下一轮 rebase 继续报同一个冲突 - 如果发现当前这个提交根本没必要存在，可以
git rebase --skip（慎用，会丢提交）
最容易被忽略的一点：rebase 改写的是提交哈希值，哪怕内容完全一样，git push 也会失败，必须用 git push --force-with-lease ——它会检查远程分支是否被别人动过，比裸 --force 安全得多。
