团队开发中，公共分支合并建议用 merge 保留历史轨迹，本地私有分支整理可用 rebase 保持线性，严禁在多人协作的共享分支上执行 rebase。
先说结论：merge 适合公共分支合并以保留完整历史，rebase 适合本地私有分支整理以保持历史线性，核心风险在于 rebase 会重写历史。
- 适合：merge 用于功能分支合并回主分支，rebase 用于同步上游代码到本地功能分支。
- 重点看：rebase 会改变提交哈希值，merge 会创建新的合并提交节点。
- 别忽略：在公共分支上使用 rebase 会导致团队成员历史冲突甚至丢失提交。
命令速用版
# 合并分支（保留历史）
git checkout main
git merge feature-branch
# 变基分支（整理历史）
git checkout feature-branch
git rebase main为什么会这样
Git 的提交对象包含父提交哈希值，任何元数据变化都会生成新的 SHA-1 哈希。merge 操作创建一个新的合并提交，指向两个父节点，保留分支分叉结构；rebase 操作则是将当前分支的提交逐个“复制”到目标分支顶端，重新应用提交，因此提交哈希值会改变，历史变成线性。
分步处理与冲突解决
1. 同步远程代码：执行 git fetch origin 获取最新状态。
2. 本地整理提交：在本地功能分支执行 git rebase origin/main。
3. 冲突处理流程：若 rebase 过程中出现冲突，Git 会暂停变基。
- 编辑冲突文件，手动解决冲突标记。
- 执行
git add <conflicted_file>标记解决。 - 执行
git rebase `--continue`继续变基。 - 若需放弃，执行
git rebase `--abort`恢复原状。
4. 合并回主分支：切换回主分支，使用 git merge `--no-ff` feature-branch 合并。
5. 推送代码：执行 git push，若 rebase 过本地分支需使用 git push `--force-with-lease` 强制推送，并再次确认分支独占性。
怎么验证是否生效
使用 git log `--graph` `--oneline` 查看提交历史。
Merge 效果示例：
* Merge branch 'feature'
|\
| * Feature commit
* | Main commit
|/
* Base commitRebase 效果示例：
* Feature commit (rebased)
* Main commit
* Base commit同时检查 CI/CD 流水线是否通过。
常见坑与安全实践
1. 公共分支变基：严禁对多人开发的分支（如 main/dev）执行 rebase，会导致协作者历史混乱。
2. 强制推送风险：rebase 后历史改变，推送需强制操作。建议使用 git push `--force-with-lease` 代替 `--force`，前者会在远程分支被他人更新时拒绝推送，避免覆盖他人代码。
3. 冲突处理：rebase 过程中每个提交都可能冲突，需逐个解决并提交，中途放弃需用 git rebase `--abort`。