安全 Rebase 手册 🚦

什么是 Rebase？

简单理解，rebase 就是把你当前分支上的提交“搬家”，放到目标分支（通常是 main）的最新提交之后。
就像你写的代码排队等着接力跑，把你的改动“重新插队”到最新代码后面。

为什么要用 Rebase？

  • 保持提交历史整洁、线性 🧹
  • 方便回顾和审查代码 🔍
  • 避免一堆杂乱的合并提交（merge commits） 🌀

但 Rebase 有啥坑？

  • 频繁冲突，像“搬家拆迁”现场 🏚️
  • 改历史可能导致别人分支失效 💥
  • 中断没解决冲突，Git 状态乱成一锅粥 🍲

安全 Rebase 操作步骤 🛡️

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
# 1. 确保工作区干净（无未提交改动）
git status
# 如果有改动，先提交或 stash
git add .
git commit -m "work in progress"      # 提交
# 或者
git stash                              # 临时存储

# 2. 切到你的开发分支（feature 分支）
git checkout feature_branch

# 3. 获取远程最新代码
git fetch origin

# 4. 对你的分支执行 rebase 到最新 main
git rebase origin/main

# 5. 如果出现冲突，Git 会提示冲突文件
# 打开冲突文件，手动编辑解决冲突后：
git add <冲突文件>

# 6. 继续 rebase
git rebase --continue

# 7. 重复第5、6步，直到 rebase 完成

# 8. rebase 完成后，如果之前 stash 了改动，恢复它
git stash pop

# 9. 本地测试确保无误后，推送分支（需要强制推送）
git push -f origin feature_branch

冲突解决小Tips 💡

  • 打开冲突文件，Git 会标记冲突区域：
1
2
3
4
5
<<<<<<< HEAD
你的代码（main 分支的代码）
=======
你的改动（feature 分支代码）
>>>>>>> commit_hash

  • 手动编辑成正确的代码，然后保存并 git add

  • 冲突复杂时，多和同事沟通，确认改动意图

  • 避免随意“全用某一方代码”，除非很确定

Rebase 常见误区 ⚠️

错误操作 可能结果 正确做法
直接在未提交改动状态下 rebase 被 Git 阻止或状态混乱 先提交或 stash 干净工作区
中断冲突解决直接退出 rebase Git 状态半完成，分支混乱 解决冲突后 git rebase --continue
多人对同一分支强制推送 代码历史被覆盖，别人代码丢失 约定分支管理和推送规则

画个流程图，帮你理解更清楚 🔄

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
[开始]
   |
   v
[检查工作区干净?] --否--> [提交或stash]
   |
   是
   v
[git fetch origin]
   |
   v
[git rebase origin/main]
   |
   v
[出现冲突?] --否--> [完成rebase]
   |
   是
   v
[解决冲突并git add]
   |
   v
[git rebase --continue]
   |
   v
[回到出现冲突?]

小结

  • 保证工作区干净，提交或 stash 先行

  • rebase 遇冲突耐心解决，别着急放弃

  • rebase 完后测试，再强推到远程

  • 团队统一流程，避免踩雷