学会rebase，多一个代码更新的选择

前言

前几天上线，由于上线窗口的代码已经发布完毕，master已更新，流水线提示我执行rebase master后重新提交，我细看值周文档，赫然写着： 不会rebase找你师父！

rebase：变基，指将当前分支的提交历史「重新嫁接」到另一个分支的最新提交之上。 这个指令直观感受不如merge稳妥，尤其当你着急上线，让你去用一个不熟悉的指令，多少都有点慌。现在赶快学习一下，下次用起来！

场景模拟

假设你在feature分支开发，其他同学提交更改到master，此时你的分支版本落后于master的版本，例如下图状态：

此时如果你想要提交代码，git会提示你先拉取最新更改到分支，再提交。下面有两个解决方案，应该是经常使用git的朋友都会的操作：

1. git stash： 把自己的更改暂存起来，pull完再stash pop
2. git merge： 将master代码merge到自己的分支

然而git rebase会用的人真的很少，只要你学会rebase和merge的区别，下次无脑用起来。

两者区别

git merge：保留完整历史的协作方式

操作步骤

bash
# 1. 切换到自己的功能分支
git checkout feature/cart

# 2. 将main分支合并到当前分支
git merge master

提交历史结果

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
# 1. 切换到功能分支
git checkout feature/cart

# 2. 将当前分支的提交"嫁接"到master分支最新提交之后
git rebase master

提交历史结果

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等工具直观查看分支拓扑。