大家工作日常用merge还是rebase呢？
今天用一个形象的 分支节点图 和 场景故事 来解释 merge 和 rebase 的区别，帮助你理解它们如何影响提交的历史的。
场景设定
假设你有一个主分支 main，初始提交为 A。你从 A 切出一个功能分支 feature，并做了两次提交 B 和 C。与此同时，主分支 main 也有其他人推送了新的提交 D 和 E。
初始状态：
B---C (feature)
/
A---D---E (main)
你的目标是将 feature 分支的代码合并到 main 分支，但有两种不同的策略：merge 和 rebase。
1. 使用 merge 合并
执行命令：
git checkout main
git merge feature
合并后的历史：
B---C (feature)
/ \
A---D---E---F (main)
• 特点：
• 生成一个新的 **合并提交 F**，明确记录分支交汇点。
• feature 分支的原始提交 B 和 C 被保留，历史完整。
• main 分支的历史是 非线性的，能看到分支的分叉和合并。
• 适用场景：
• 公共分支协作（如团队开发）。
• 需要保留完整的分支合并记录。
2. 使用 rebase 合并
执行命令：
git checkout feature
git rebase main # 将 feature 的 B 和 C 变基到 main 的 E 之后
git checkout main
git merge feature # 此时是快进合并（fast-forward）
合并后的历史：
A---D---E---B'---C' (main, feature)
• 特点：
• feature 的提交 B 和 C 被 复制 为新的提交 B' 和 C'（哈希值改变）。
• main 分支的历史是 完全线性的，没有分叉。
• 原始提交 B 和 C 被丢弃（如果分支已推送，需要强制推送 git push --force）。
• 适用场景：
• 个人分支整理（未推送的提交）。
• 希望提交历史保持整洁线性。
关键区别对比
| 操作 | ||||
|---|---|---|---|---|
merge |
||||
rebase |
形象的比喻
• merge 像搭桥：
在两条分支之间建一座桥（合并提交 F），保留两条分支的原始路径。所有人都能清晰看到从哪里分叉、在哪里合并。
• rebase 像时光机：
把 feature 分支的修改“时间旅行”到 main 分支的最新状态，假装你的工作一直基于最新的代码，但篡改了历史（原始提交消失）。
实际协作中的问题
如果 feature 分支已推送到远程仓库：
**用 merge**：其他人能看到一致的历史，直接git pull即可同步。**用 rebase**：你需要git push --force，而其他开发者如果之前拉取过旧feature分支，他们的本地历史会与远程冲突，必须手动修复。
通过上面的对比，我认为rebase在团队合作中会存在一些风险，merge 更安全的核心原因是不修改历史，而 rebase 的风险来自历史重写。
优网科技秉承"专业团队、品质服务" 的经营理念，诚信务实的服务了近万家客户，成为众多世界500强、集团和上市公司的长期合作伙伴！
优网科技成立于2001年，擅长网站建设、网站与各类业务系统深度整合，致力于提供完善的企业互联网解决方案。优网科技提供PC端网站建设（品牌展示型、官方门户型、营销商务型、电子商务型、信息门户型、DIY体验、720全景展厅及3D虚拟仿真）、移动端应用（手机站、APP开发）、微信定制开发（微信官网、微信商城、企业微信）、微信小程序定制开发等一系列互联网应用服务。
公安局备案号：
专属顾问
