rebase会改变所有提交的sha-1哈希值，因原提交被丢弃并重写为新提交；merge仅新增一个合并提交，原有提交哈希完全不变，确保外部引用（如ci、pr评论、jira链接）持续有效。
rebase 会改提交哈希，merge 不会
这是最根本的区别，不是“看起来线性不线性”的问题，而是 SHA-1（或 SHA-256）值是否变化。rebase 把你的每个提交都“复制”成新提交，原提交被丢弃，所有新提交的哈希全变；merge 只新增一个合并提交，原有提交哈希完全不动。
这意味着：如果你在 PR 里被评论了某行代码、CI 构建记录绑定了 abc1234、Jira 工单链接了那个 commit，rebase 后这些全部失效——因为 abc1234 已不存在。而 merge 后，旧提交还在，所有外部引用照常工作。
常见错误现象：
— 在已推送到远程的 feature/login 上执行 git rebase main，再 git push 被拒绝
— 同事基于你旧提交做的 code review 评论突然“找不到对应 commit”
— CI 流水线重复构建，缓存命中率暴跌
什么时候该用 git merge
只要分支已共享（即别人能拉、能基于它开发），就该用 merge。尤其是 main、develop、release/* 这类长期存在的公共分支。
使用场景包括：
— 把功能分支合入 main（发布前）
— 把 main 的 hotfix 合入正在开发的 feature/* 分支（保持同步）
— 多人协作中任何需要保留可追溯协作痕迹的操作
注意：git merge --no-ff 是推荐做法，即使能快进也强制生成合并提交，确保每次集成都有明确记录；默认快进（fast-forward）会抹掉分支存在痕迹，不利于回溯。
什么时候该用 git rebase
只有一种安全场景：你自己的、尚未 git push 到远程的本地分支。
监控一个或多个 GitCode 仓库的 PR，通过 OpenClaw Gateway 自动执行 AI 审查，发布 PR 评论，并发送钉钉和企业微信通知。
典型操作流：
— git checkout -b feature/search
— 写了 3 个提交：add input field、implement search logic、fix typo in placeholder
— 此时 main 已有新提交 → 用 git rebase main 把这 3 个提交“叠”到最新 main 顶端
— 再 git push origin feature/search
如果已经推过又想 rebase：
— 必须加 --force-with-lease（不是 --force），它会检查远程分支是否被他人更新，避免覆盖别人的新提交
— 冲突时，解决后 git add .，再 git rebase --continue；不想继续就 git rebase --abort
交互式 rebase（rebase -i）是整理本地提交的唯一靠谱方式
别在写完一堆 git commit -m "wip"、"fix again" 后，手动 reset + add + commit。风险高、易丢改动。
正确做法：
— git rebase -i HEAD~5（调整最近 5 次提交）
— 编辑器里把想合并的提交前的 pick 改成 squash 或 fixup
— 保存退出后，Git 会自动合并提交并打开编辑器让你重写 commit message
— 完成后历史干净，且仍是本地未推送状态，安全
容易踩的坑：
— 对已推送分支做 rebase -i 后直接 push → 强制推送前必须确认没人基于你旧提交工作
— 在 rebase -i 中误删某行提交 → 那个提交永久丢失（除非从 reflog 找）
— squash 后没改 commit message → 默认拼接，可能含无意义的 “wip” 文本
真正难的不是命令怎么敲，而是判断“这个分支到底算不算已共享”。只要远程仓库里有同名分支，哪怕只有你自己 push 过，也应默认视为已共享——因为 Git 无法区分“谁 push 的”，只认有没有对应 ref。
