前言
前几天上线，由于上线窗口的代码已经发布完毕，master已更新，流水线提示我执行rebase master后重新提交，我细看值周文档，赫然写着： 不会rebase找你师父！
rebase：变基，指将当前分支的提交历史「重新嫁接」到另一个分支的最新提交之上。 这个指令直观感受不如merge稳妥，尤其当你着急上线，让你去用一个不熟悉的指令，多少都有点慌。现在赶快学习一下，下次用起来！
场景模拟
假设你在feature分支开发，其他同学提交更改到master，此时你的分支版本落后于master的版本，例如下图状态：
此时如果你想要提交代码，git会提示你先拉取最新更改到分支，再提交。下面有两个解决方案，应该是经常使用git的朋友都会的操作：
- git stash： 把自己的更改暂存起来，pull完再stash pop
- git merge： 将master代码merge到自己的分支
然而git rebase会用的人真的很少，只要你学会rebase和merge的区别，下次无脑用起来。
两者区别
git merge：保留完整历史的协作方式
操作步骤
bash
bash
# 1. 切换到自己的功能分支
git checkout feature/cart
# 2. 将main分支合并到当前分支
git merge master提交历史结果
markdown
markdown
* 93e4d20 (HEAD -> feature/cart) Merge branch 'master' into feature/cart
|\
| * 5a1b2f3 (master) fix: 紧急修复错误
* | 82c7a1d feat: 添加功能
* | 0d9e6d8 feat: 添加功能
|/
* e8f3a1d init: 项目初始化核心特点
- 保留分支拓扑 ：通过
merge commit明确记录两个分支的交汇点。 - 协作友好 ：适合公共分支（如
master）合并，避免重写历史导致他人混乱。 - 历史更真实：完整展示开发过程中的并行进展。
git rebase：追求线性历史的代码整理术
操作步骤
bash
bash
# 1. 切换到功能分支
git checkout feature/cart
# 2. 将当前分支的提交"嫁接"到master分支最新提交之后
git rebase master提交历史结果
markdown
markdown
* 9f2a871 (HEAD -> feature/cart) feat: 添加功能
* 7b3c6d5 feat: 实现功能
* 5a1b2f3 (master) fix: 修复错误
* e8f3a1d init: 项目初始化核心特点
- 历史线性化：消除分叉，提交按时间顺序排列，便于代码审查。
- 本地分支优化：适合整理尚未推送的本地提交（如合并多个WIP提交）。
- 风险提示 ：禁止对已推送的公共分支使用
rebase，会破坏他人代码历史。
关键决策指南
| 维度 | git merge |
git rebase |
|---|---|---|
| 历史记录 | 保留分支结构，存在合并提交 | 线性历史，无额外合并节点 |
| 适用场景 | 合并公共分支（如master到feature） |
整理本地分支提交 |
| 协作影响 | 安全，不影响他人 | 仅限未推送的本地分支 |
| 冲突处理 | 一次性解决所有冲突 | 可能需在每个提交上重复解决冲突 |
总结
具体使用可遵循以下几点：
- 黄金法则 ：
正在协作的分支用merge，私有分支用rebase。 - 团队规范优先 ：
统一选择merge或rebase策略，避免历史记录风格混乱。 - 可视化工具辅助 ：
使用git log --graph或SourceTree等工具直观查看分支拓扑。