merge将所有冲突集中一次解决，rebase则按每个提交逐个重放并逐个解决冲突；前者安全可控、适合公共分支，后者易引发重复冲突与历史改写风险，仅限未推送的本地分支使用。
冲突爆发时，Merge 和 Rebase 的处理路径完全不同
Merge 把所有冲突集中到一次解决，Rebase 则把冲突拆开，按每个提交逐个重放、逐个解决。这不是“谁更简单”的问题，而是“你愿不愿意在每个提交里都面对同一块代码的冲突”。
常见错误现象：git rebase 过程中反复遇到同一处文件冲突，改完一个提交后，下一个提交又提示同一行冲突；而 git merge 只报一次冲突，解决完就能直接提交。
- Merge 冲突发生在合并提交节点，只触发一次冲突检测和解决流程
- Rebase 冲突发生在每个待重放提交上——哪怕只是两个相邻提交都改了
src/api/auth.js的同一函数，也会各自触发一次冲突 - 如果 feature 分支有 12 个提交，其中 4 个涉及同一模块，Rebase 很可能让你重复解决 4 次相似冲突
- Rebase 中一旦
git add+git rebase --continue错误跳过某次冲突修复，后续提交会基于错误状态继续应用，导致逻辑错乱
已经推送过的分支，绝对不要 git rebase
只要 feature/login 已执行过 git push origin feature/login，再对它做 git rebase main 就等于单方面改写历史——远程分支的提交哈希全变了，别人 git pull 会拿到断裂的历史，git log 看不到共同祖先，协作立即卡死。
真实场景：同事 A 在你 rebase 后 git pull，Git 提示 “fatal: refusing to merge unrelated histories”，或拉下来一堆重复提交；CI 流水线因 commit hash 不匹配而失败。
CNB 云原生构建平台的 Git 操作技能，支持代码克隆、提交、推送、分支管理、Merge Request 管理、流水线触发与结果读取。初次使用需收集用户的 Git 用户名和邮箱。
- 唯一例外：团队明确约定并启用
git push -f，且所有人同步执行git fetch && git reset --hard origin/feature/login -
git pull --rebase是安全的，因为它只影响本地HEAD，不触碰远程已存在分支 - 判断是否已推送：运行
git branch -v，若看到origin/feature/login对应的 commit hash 与本地不同，说明已有他人基于旧历史工作
当主分支频繁更新，Merge 产生的“分叉毛刺”比 Rebase 更可控
很多人反感 Merge 带来的非线性历史，但实际项目中，git merge main 生成的“毛刺”远比 git rebase main 引发的隐性风险更容易管理。
原因在于：Merge 的分叉是显式的、可追溯的；Rebase 的线性是伪造的，掩盖了真实开发节奏，且一旦出错无法回退到原状。
- Merge 失败可随时
git merge --abort，回到合并前状态 - Rebase 失败后，
git rebase --abort能恢复，但若已git push -f，原始提交在远程彻底丢失 - CI/CD 工具（如 GitHub Actions）依赖 commit hash 触发构建，Rebase 后所有 hash 变更，会导致缓存失效、构建重复、部署标记错乱
- 审计需求下，Merge 提交自带
Merge: feature/login into main元信息，Rebase 后只剩孤立提交，无法关联原始分支上下文
git merge --no-ff 是公共分支合并的底线配置
默认 git merge 在快进（fast-forward）时不会生成合并提交，导致 feature 分支消失在历史里——这会让“哪个提交属于哪个功能”完全不可查。
强制非快进合并，才能确保每次整合都有明确锚点。
- 正确做法：
git checkout main && git merge --no-ff feature/login - 错误做法：
git merge feature/login（无参数，依赖默认行为） - 团队级防护：在
.git/config或全局 config 中设merge.ff = false，让所有git merge默认禁用快进 - CI 自动化检查：在 PR 合并前校验目标分支最新提交是否为 merge commit，否则拒绝合并
