merge是公共分支合并的唯一合理选择，因其创建双父提交、保留完整历史，支撑回滚、bisect与审计；rebase仅适用于未推送的私有分支整理，严禁用于main/develop等共享分支。
别用 rebase 合并到 main 或 develop 分支——这是最常踩的线上事故入口。 merge 是安全合并的默认选择；rebase 只该用在你一个人写的、还没推送到远程的私有分支上。
git merge 为什么是公共分支合并的唯一合理选择
merge 创建一个带两个父提交的新提交，完整保留两个分支各自的演进路径。这不只是“好看”，而是线上回滚、bisect 定位、审计追踪的底层依据。
- 一旦
main或develop被多人基于开发，它的提交哈希就已成为团队协作的共识锚点；git rebase会重写这些提交，导致他人本地分支失效、git pull变成灾难性重同步 - CI/CD 流水线依赖提交 SHA 做构建缓存和部署标记；rebase 后的提交 SHA 全变，缓存失效、部署链断裂、发布记录对不上
- 即使你只 rebase 自己的 feature 分支再 merge，只要这个分支已被
git push --force-with-lease过（比如为解决冲突强推），队友git fetch后看到的 reflog 就已污染，后续git reset极易误删未备份的提交
git rebase 的真实适用场景只有这一个
你在本地写了 5 个提交，但它们语义混杂：有调试日志、有临时注释、有拆一半的重构——此时用 git rebase -i HEAD~5 整理成 2 个逻辑清晰、可读性强的提交，再 git push 到远程 feature 分支。
- 必须满足：该分支尚未被他人
git checkout、git merge或用于 CI 构建；否则就是把历史变更强加给别人 - rebase 后若需推送，只能用
git push --force-with-lease，绝不能用--force；前者会检查远程引用是否被他人更新，后者直接覆盖，风险不可逆 -
git rebase过程中每遇到一次冲突，就要git add+git rebase --continue；不是一次性解决完再继续，这点和git merge完全不同
merge 提交里出现 “Already up to date” 却没真合并？
这是 git merge 检测到当前分支已经包含目标分支全部提交时的提示，不是 bug，而是 fast-forward 的表现。它意味着 Git 直接移动了当前分支指针，不产生新提交。
- 想强制生成 merge commit（比如为了统一记录合并行为），加
--no-ff参数：git merge --no-ff feature-login - 如果执行
git merge后工作区没变化、也没有新提交，先运行git status确认是否已在目标分支；再用git log --oneline --graph --all看实际分支拓扑 - 某些 GUI 工具或 IDE 插件会默认启用
--ff-only，导致无法 merge 非直系分支，需查对应配置项关闭
rebase 后 git push 失败：rejected non-fast-forward 怎么办
这是 Git 在保护你：远程分支比你本地“新”，而你的本地分支已被 rebase 重写过，二者已无共同祖先。
- 第一反应不是强行覆盖，而是先
git fetch origin，再git rebase origin/main（或对应目标分支），把远程新提交也纳入你的重写流程 - 如果已有队友基于你旧的 feature 分支开发，立刻停手；沟通确认后，所有人需
git reset --hard origin/feature-old回退，再基于新分支重建工作 - 长期来看，把
push.default设为simple（Git 2.0+ 默认），并禁用git config --global push.forceWithLease true，能从 CLI 层级降低误操作概率
真正难的从来不是命令怎么敲，而是判断「这个分支此刻算不算我的私人草稿」——只要它被别人 git clone 过、git checkout 过、甚至只是出现在团队共享的 PR 列表里，它就不再是你的私人分支。
