Git Rebase 是什么？为什么需要它？
你目前的使用流程是：
bash
git checkout <branch> # 切换到某个分支
git push # 把本地提交推到远程这种方式简单直接，但当你和团队多人协作时，经常会出现分支历史分叉 的情况。这时 git rebase 就是一个非常强大的工具，它能让你的提交历史变得更干净、更线性。
先看一个常见问题场景
假设主分支是 main，你从它拉了一个功能分支 feature：
main: A --- B --- C
\
feature: D --- E (你的两个提交)你开发完了，想把 feature 合并回 main。
如果你用最常见的 git merge，会产生一个合并提交（merge commit）：
main: A --- B --- C --- F (F 是合并提交)
\ /
feature: D --- E历史看起来有分叉，不够线性，尤其多人协作时，历史会变得乱糟糟。
git rebase 的作用：把你的提交"挪动"到最新主分支后面
用 git rebase 后，Git 会做这件事：
- 找到
main和feature的共同祖先（B） - 把你的提交 D 和 E 暂时保存起来
- 把
feature分支指针直接指向最新的main（C） - 把你的提交 D 和 E 一个个重新应用（replay）到 C 后面
结果变成一条直线：
main: A --- B --- C --- D' --- E'D' 和 E' 是内容和你原来的 D、E 完全一样，但提交时间和 hash 变了（因为基于新的父提交）。
历史变得超级干净，像你是一直在最新代码上开发的一样。
如何使用 git rebase（最常见命令）
bash
# 1. 先切换到你的功能分支
git checkout feature
# 2. 把主分支最新内容拉下来
git fetch origin
# 3. 把你的分支变基到最新的 main 上
git rebase origin/main如果一切顺利，就直接变成线性历史了。
然后你就可以强制推上去（因为历史被改写了）：
bash
git push --force-with-lease # 推荐用这个，比 --force 更安全可能遇到冲突怎么办？
rebase 过程中如果你的修改和主分支新代码有冲突，Git 会暂停，告诉你哪个文件冲突。
解决方法：
bash
# 编辑冲突文件，解决 <<<<< ===== >>>>> 标记
git add <解决好的文件>
# 继续 rebase 过程
git rebase --continue如果想放弃 rebase：
bash
git rebase --abort # 回到 rebase 之前的状态rebase vs merge 对比（帮你选择）
| 特点 | git merge | git rebase |
|---|---|---|
| 历史是否线性 | 不线性（有分叉和合并提交） | 线性（一条直线） |
| 是否保留真实历史 | 是（完整记录谁什么时候合并） | 不是（改写了提交历史） |
| 历史是否干净易读 | 较乱，尤其多人协作 | 非常干净 |
| 是否安全 | 非常安全，不会改写历史 | 需要谨慎（尤其是已推送的提交） |
| 团队常用场景 | 公共分支（如 main、develop） | 个人功能分支合并前清理历史 |
业界常见实践（尤其是 GitHub/GitLab 项目）：
- 功能分支开发时：用
rebase保持最新 + 干净历史 - 合并到主分支时：用 Pull Request / Merge Request，底层常用 rebase and merge（先rebase再快进合并，无合并提交）
总结：你为什么应该学 git rebase
你现在只用 checkout 和 push，已经能完成基本工作。但学会 rebase 后：
- 你的分支永远基于最新代码，减少后续合并冲突
- 提交历史干净整齐，别人 review 代码更舒服
- Pull Request 看起来更专业（一条直线 vs 乱七八糟的分叉）
- 避免不必要的 merge commit 污染历史
建议上手步骤
-
在一个不重要的分支试试：
bashgit checkout feature git fetch git rebase origin/main -
看历史变化：
git log --oneline --graph -
成功后用
git push --force-with-lease
等你习惯了，就会发现 rebase 是日常开发中最常用、最爽的 Git 命令之一！
后记
2026年1月7日于上海，在grok fast辅助下完成。