安全 Rebase 手册 🚦

什么是 Rebase？

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

为什么要用 Rebase？

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

但 Rebase 有啥坑？

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

安全 Rebase 操作步骤 🛡️

# 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 会标记冲突区域：

<<<<<<< HEAD
你的代码（main 分支的代码）
=======
你的改动（feature 分支代码）
>>>>>>> commit_hash

手动编辑成正确的代码，然后保存并 git add
冲突复杂时，多和同事沟通，确认改动意图
避免随意“全用某一方代码”，除非很确定

Rebase 常见误区 ⚠️

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

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

[开始]
   |
   v
[检查工作区干净?] --否--> [提交或stash]
   |
   是
   v
[git fetch origin]
   |
   v
[git rebase origin/main]
   |
   v
[出现冲突?] --否--> [完成rebase]
   |
   是
   v
[解决冲突并git add]
   |
   v
[git rebase --continue]
   |
   v
[回到出现冲突?]

小结

保证工作区干净，提交或 stash 先行
rebase 遇冲突耐心解决，别着急放弃
rebase 完后测试，再强推到远程
团队统一流程，避免踩雷