核心思想是用 git rebase 替代 git merge 同步远程更新，避免冗余 merge 提交，保持历史线性可读；因 git pull 默认执行 fetch + merge，本地有未推送提交时会生成 merge commit，导致分支图分叉、log 难追踪，而 rebase 将本地提交重放到远程最新基准上，不新增节点，但需注意仅限功能分支使用，公共分支禁止 force push。
核心思想就一条：**用 git rebase 替代 git merge 同步远程更新，避免产生冗余 merge 提交，保持分支历史线性可读。**
为什么不能直接 git pull
git pull 是 git fetch + git merge 的组合操作。一旦本地有未推送的提交，git merge 就会生成一条 merge commit —— 这不是“同步”，而是“合流”，会让分支图出现分叉。多人协作中，这种分叉会快速堆积，导致 git log --graph 难以追踪真实开发脉络。
常见错误现象：
- 执行
git pull origin dev后，git log --oneline出现类似a1b2c3d Merge branch 'origin/dev' into dev的提交 - 团队成员反复拉取后，dev 分支历史里嵌套多层 merge 提交，回滚或 bisect 变得困难
git rebase 同步的正确姿势
本质是把本地未推送的提交“重放”到远程最新基准上，不新增 merge 节点，历史保持一条直线。
实操步骤（以本地 dev 分支同步远程 origin/dev 为例）：
- 先运行
git fetch origin dev，只拉取远程最新状态，不碰本地工作区 - 再运行
git rebase origin/dev，将本地dev分支所有未推送提交，依次应用到origin/dev最新提交之后 - 若出现冲突，手动解决后
git add . && git rebase --continue，不要git commit - 完成后
git push --force-with-lease origin dev推送（仅限你独占的 feature 分支；主干分支如dev禁止 force push）
注意：git rebase 会改写提交哈希，已推送过的提交被变基后，必须用 --force-with-lease，不能用 --force，防止覆盖他人新提交。
本地有未提交修改时怎么安全同步
直接 rebase 会失败，因为工作区不干净。此时 git stash 是唯一安全入口。
- 运行
git stash push -m "wip: sync before rebase"，把当前修改暂存 - 再执行
git fetch origin dev && git rebase origin/dev - 最后
git stash pop恢复修改，如有冲突，在暂存恢复阶段处理，而非 rebase 过程中
别用 git stash apply 后忘记 drop，多个 stash 堆积会导致误恢复旧版本。
多人共用分支（如 dev）的特殊约束
这类分支禁止个人 rebase 或 push --force，否则会破坏他人本地历史。
- 同步方式只能是
git fetch origin dev && git merge origin/dev（接受 merge 提交） - 但必须确保 merge 前本地无未推送提交——即每次 push 完立刻 fetch，避免积累多个本地提交
- 更稳妥的做法：所有人在
dev上只做 fast-forward 合并（即远程无新提交时才 push），否则先fetch再merge
真正容易被忽略的是：**分支用途决定同步策略**。功能分支可大胆 rebase；集成分支（dev/main）必须守序，宁可多 merge 提交，也不许重写历史。
