大家工作日常用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 的风险来自历史重写。
優(yōu)網(wǎng)科技秉承"專業(yè)團(tuán)隊(duì)、品質(zhì)服務(wù)" 的經(jīng)營(yíng)理念，誠(chéng)信務(wù)實(shí)的服務(wù)了近萬(wàn)家客戶，成為眾多世界500強(qiáng)、集團(tuán)和上市公司的長(zhǎng)期合作伙伴！
優(yōu)網(wǎng)科技成立于2001年，擅長(zhǎng)網(wǎng)站建設(shè)、網(wǎng)站與各類業(yè)務(wù)系統(tǒng)深度整合，致力于提供完善的企業(yè)互聯(lián)網(wǎng)解決方案。優(yōu)網(wǎng)科技提供PC端網(wǎng)站建設(shè)（品牌展示型、官方門戶型、營(yíng)銷商務(wù)型、電子商務(wù)型、信息門戶型、DIY體驗(yàn)、720全景展廳及3D虛擬仿真）、移動(dòng)端應(yīng)用（手機(jī)站、APP開發(fā)）、微信定制開發(fā)（微信官網(wǎng)、微信商城、企業(yè)微信）、微信小程序定制開發(fā)等一系列互聯(lián)網(wǎng)應(yīng)用服務(wù)。
公安局備案號(hào)：
專屬顧問
