git rebase 变基操作教程


⭐⭐⭐⭐⭐ 最优解(强烈推荐)

本质一句话:

🔥 让 branch2 "搬家" 到 main 上面。

Git 专业术语叫:

👉 rebase

可以理解为:

把你的分支从旧地基 → 挪到新地基

非常形象。


🚀 傻瓜式操作(按顺序复制)

✅ Step 1 --- 确认 stash 在

先保存修改的代码

git stash

先看:

复制代码

git stash list

如果看到:

复制代码

stash@{0}

说明安全 👍

(这一步是防手残)


✅ Step 2 --- 拉最新 main

切过去:

复制代码

git checkout main

更新:

复制代码

git pull --rebase


为什么?

避免:

你 rebase 到一个"过期的 main"。

否则等于白折腾一次。


✅ Step 3 --- 切回 branch2

复制代码

git checkout branch2


⭐⭐⭐⭐⭐ Step 4 --- 核心操作(最关键)

直接执行:

复制代码

git rebase main

就这一句。


🔥 发生了什么?(人话版)

Git 在做:

复制代码

找到 branch2 和 main 的分叉点 把 branch2 的提交一个个摘下来 重新贴到 main 后面

结果变成:

复制代码

main (最新) ↓ branch2

branch1?

👉 彻底被绕过了。

可以当它不存在。


🚨 如果出现冲突(非常正常)

看到:

复制代码

CONFLICT ...

别怕,这是 Git 的日常。

操作三步:

① 打开冲突文件

删除:

复制代码

<<<<<<< ======= >>>>>>>

改成你要的最终代码。


② 标记解决:

复制代码

git add .


③ 继续 rebase:

复制代码

git rebase --continue

重复直到结束。

(一般不会很多)


✅ Step 5 --- 恢复你的 stash

复制代码

git stash pop

现在:

复制代码

最新 main + 你的 branch2 提交 + 你刚写的代码

完美融合 👍


✅ Step 6 --- 提交

复制代码

git add . git commit -m "feature"

完成 🎉


⭐⭐⭐⭐⭐ 为什么这是"最正确"的?

🚨 千万别用 merge

很多人会这样:

复制代码

git merge main

结果历史会变:

复制代码

Merge branch 'main'

然后:

  • 提交树像蜘蛛网 🕸️

  • Tech Lead 看了想打人

  • 排查 bug 极痛苦


🔥 rebase 的巨大优势:

✅ 提交历史是一条直线

看起来像:

复制代码

main → commit → commit → branch2

非常专业。

大厂几乎默认:

feature 分支必须 rebase 主线


⭐⭐⭐⭐⭐ 一个超级重要判断

❗ branch1 已经废弃?

那就:

👉 永远不要再管它。

甚至建议删除:

复制代码

git branch -D branch1

(确定没人用再删)


⭐⭐⭐⭐⭐ 再教你一个"更傻瓜"的写法(神器)

以后直接:

复制代码

git pull --rebase --autostash origin main

Git 自动:

✅ stash

✅ rebase

✅ pop

一条龙。

建议直接设为默认:

复制代码

git config --global rebase.autoStash true


⭐⭐⭐⭐⭐ 最终给你一个"无脑口诀"

以后遇到:

旧分支 → 想跟新主线

直接:

复制代码

stash checkout main pull checkout 我的分支 rebase main stash pop commit

完事。


🔥 再送你一个"高手认知"(非常值钱)

👉 永远:

feature 分支只从主线切!

不要:

复制代码

branchA → branchB → branchC

否则:

冲突概率暴涨。

这是很多团队 Git 混乱的根源。

复制代码

⭐⭐⭐⭐⭐ 现在你"必须"做的一步(很多人会忘)

👉 检查分支结构!

打:

复制代码

git log --oneline --graph --decorate -15

理想结构应该像:

复制代码

main ↓ commit ↓ release-cantilever-shaft (HEAD)

而不是:

复制代码

branch1 ↓ release...


🚨 下一步非常关键(90%新人不知道)

❗ 如果这个分支之前 push 过远程:

必须用:

复制代码

git push -f

注意:

⚠️ 是 -f(force)


为什么必须 force?

因为:

🔥 rebase = 改写历史

提交 hash 已经变了:

复制代码

旧:9188a2b 新:90194d2

Git 会拒绝普通 push。


但更安全的写法是:

强烈推荐:

复制代码

git push --force-with-lease

-f 安全很多。

它会防止:

你把同事的提交冲掉。

大厂基本只允许这个。


⭐⭐⭐⭐⭐ 再帮你判断一件重要的事

👉 branch1 已废弃?

建议直接删:

本地:

复制代码

git branch -D branch1

远程:

复制代码

git push origin --delete branch1

(确认没人用再删)


🔥 给你一个高手级判断(30秒检查是否健康)

打:

复制代码

git status

如果看到:

复制代码

nothing to commit, working tree clean

说明:

⭐⭐⭐⭐⭐ 你的仓库非常干净。



🚀 再送你一个"避免未来90%冲突"的建议

以后养成习惯:

每天写代码前:

复制代码

git pull --rebase

不要等:

写了2天 → 再 rebase

那会冲突到怀疑人生。


⭐ 最后帮你确认一下当前状态

从你的日志看:

✅ stash ✔

✅ rebase main ✔

✅ 冲突解决 ✔

✅ 分支更新 ✔

你现在只差一步:

👉 如果 stash 里还有代码:

查看:

复制代码

git stash list

有的话:

复制代码

git stash pop

然后提交即可。

相关推荐
Selicens1 天前
git批量删除本地多余分支
前端·git·后端
闲云一鹤2 天前
Git LFS 扫盲教程 - 你不会还在用 Git 管理大文件吧?
前端·git·前端工程化
vibecoding日记5 天前
为什么我就想要「线性历史 + Signed Commits」,GitHub 却把我当猴耍 🤬🎙️
git·编程工具
程序员小崔日记5 天前
如何将代码轻松上传到 Gitee?Git 使用全攻略!
git·gitee·上传
Bigger6 天前
为什么你的 Git 提交需要签名?—— Git Commit Signing 完全指南
git·开源·github
DianSan_ERP7 天前
电商API接口全链路监控:构建坚不可摧的线上运维防线
大数据·运维·网络·人工智能·git·servlet
红豆子不相思7 天前
Tomcat 环境搭建与集群实战
服务器·git·tomcat
杰哥技术分享7 天前
Git 仓库迁移技术文档:从 CODING.net 迁移至腾讯云 CNB
git
梅孔立7 天前
Ansible 100 台服务器一键管控实战 进阶版
服务器·git·ansible