git merge vs git rebase:什么时候用哪个?
merge 保留完整分支历史,rebase 产生线性历史
对比
| 维度 | git merge | git rebase |
|---|---|---|
| 历史记录 | 保留分支和合并节点,历史完整但可能复杂 | 线性历史,干净但丢失分支信息 |
| 冲突处理 | 一次性解决所有冲突 | 逐个提交解决冲突(可能多次) |
| 安全性 | 不改变已有提交,安全 | 重写提交历史,已推送的慎用 |
| 适合场景 | 公共分支、团队协作、需要追溯 | 个人分支、整理提交、保持干净 |
| 操作复杂度 | 简单,一步完成 | 可能需要多次解决冲突 |
使用场景
什么时候用 git merge
- 合并 feature 分支到 main/develop
- 团队多人协作的分支
- 需要保留完整的开发历史
- 不确定时默认用 merge
什么时候用 git rebase
- 更新个人 feature 分支(从 main 获取最新代码)
- 提交前整理提交历史(squash)
- 想要干净的线性 git log
- 个人项目追求简洁历史
示例
mergeExample
# 将 feature 合并到 main git checkout main git merge feature-login # 产生一个合并提交
rebaseExample
# 将 feature 更新到 main 最新 git checkout feature-login git rebase main # feature 的提交移到 main 最新之后
常见错误
在公共分支上 rebase 导致其他人的历史混乱
rebase 后忘记 force push
merge 时不加 --no-ff 导致快进合并丢失分支记录
建议
日常建议:用 rebase 更新个人分支,用 merge --no-ff 合并到主分支。这样既保持个人分支干净,又保留主分支的合并记录。