这是怎么一回事
变基与合并解决的是同一个问题：把两条分支上的改动汇到一起。区别在于历史怎么记录——合并保留分叉，用一个合并提交把两侧连起来；变基把本地提交挪到目标分支顶端，历史看起来像一条直线。两者没有绝对优劣，取决于分支是否已经被别人使用。
选择的判断依据
核心判断是分支可见性：只有你自己用的分支，改写历史没有副作用，变基能让历史更干净；已经推送并被他人拉取的分支，改写会让协作者的历史分叉，此时合并更安全。其次看团队工具链，如果评审与发版流程依赖合并点来识别「一个特性」，那就需要保留合并提交。
对比
| 维度 | merge | rebase |
|---|---|---|
| 历史形态 | 保留分叉与合并点 | 线性、无合并提交 |
| 提交哈希 | 不变 | 全部重写 |
| 他人影响 | 无 | 共享分支上会打断协作者 |
| 冲突处理 | 一次解决全部矛盾 | 可能逐提交反复出现 |
| 可追溯性 | 合并点标出特性边界 | 提交像新写的，看不出先后 |
| 适用场景 | 主干集成、公共分支 | 个人分支整理、跟进上游 |
个人分支跟进主干
个人分支跟进主干
git switch feature # 切到自己的分支
git fetch origin # 取回最新主干
git rebase origin/main # 把本地提交叠到主干最新位置
git log --oneline --graph -8 # 核对是否形成线性历史把特性并入主干
把特性并入主干
git switch main # 切到主干（接收方）
git pull --ff-only # 先让主干与远端对齐
git merge --no-ff feature # 保留合并点，标出特性边界
git log --graph --oneline -10 # 复核合并结果团队约定优先：同一个仓库混用两种策略也可以，但要在贡献指南里写清楚哪些分支允许改写历史，否则协作时容易互相踩到。
变基后的分支首次推送需要强推，用 --force-with-lease 而不是 --force，能在远端存在你没见过的提交时自动拒绝覆盖。
混用两种策略的仓库里，判断某段历史经历过什么可以借助合并点与提交时间：合并提交表示这里发生过一次集成，线性区段则更可能是变基后的结果。