git merge会生成合并提交，保留分支分叉历史且不改写原有提交；git rebase则重写提交哈希、形成线性历史，适用于本地未推送分支，但不可用于已共享的公共分支。
git merge 会生成合并提交，历史分叉但安全
执行 git merge 时，Git 找到两个分支的共同祖先，把两边改动合并后创建一个新提交——这个提交有两个父提交，就是典型的“合并提交”（Merge Commit）。它不改写任何已有提交，只增加一条记录。
常见错误现象：在 PR 页面看到一堆 “Merge branch 'main' into feature” 提交，其实是反复 merge 主分支导致的冗余历史；或者团队成员 push 后你再 merge，结果出现多个嵌套合并点，log 图谱像蜘蛛网。
- 适用场景：向
main、develop这类公共分支合入功能时必须用merge - 参数差异：
git merge --ff-only强制快进，失败则中止，避免意外生成合并提交 - 性能影响：每次 merge 都要计算三路差异，大仓库里可能卡顿几秒；但历史可追溯性极强，bisect 定位 bug 更准
git rebase 不生成合并提交，但重写所有哈希值
git rebase 不是“合并”，而是把当前分支的每个提交依次复制、应用到目标分支顶端，形成线性序列。原始提交被丢弃，新提交的 commit hash 全部改变——哪怕内容一字未动。
容易踩的坑：对已 git push 到远程的分支执行 rebase，会导致队友 pull 时出现重复提交、冲突无法自动 resolve，甚至本地分支“消失”。IDEA 里点 “Rebase Onto” 前务必确认该分支没被他人跟踪。
- 使用场景：仅限本地未推送的
feature分支，比如整理 5 个临时提交为 2 个语义清晰的提交 - 冲突处理：每个提交重放时都可能触发冲突，需逐个
git add+git rebase --continue，不能跳过 - 兼容性注意：CI 系统若依赖 commit hash（如缓存 key、部署标记），变基后这些 hash 失效，可能触发全量构建
看 log 图谱就能判断用了哪种策略
运行 git log --graph --oneline --all，一眼区分：
出现 \ / 分叉结构 + 中间带字母 M 的节点 → 肯定是 merge；全是直线，且原分支提交后面多出一串 '（如 D'、E'）→ 就是 rebase 干的。
真实协作中，很多人混淆“谁该用什么”：不是“merge 更老派、rebase 更高级”，而是 merge 保真，rebase 保洁——前者面向协作可信度，后者面向个人可读性。强行统一策略反而埋雷。
