拒绝做Git“蜘蛛网”制造者!从分支管理到Rebase,带你走一遍标准开发流
很多刚接触 Git 的同学,命令背得滚瓜烂熟:pull 是拉取,push 是推送,merge 是合并。但一旦到了真实的项目开发中,面对“写到一半被叫去修紧急 Bug”、“同事改了同一行代码”等突发状况,手里的命令就不知道怎么用了。
今天,我想结合自己日常的实战经验,模拟一个真实的电商项目开发场景,带你走一遍从功能开发到紧急修复,再到代码合并的完整流程。这不仅仅是命令的堆砌,更是如何保持提交历史整洁、高效协作的“心法”。
🌿 分支管理:构建你的“平行宇宙”
在开始写代码前,先明确我们的“战场”。Git 的分支设计初衷就是为了解决多人协作互不干扰的问题。我们可以把分支想象成不同的平行宇宙:
main/master(主分支) :这是圣殿。线上正在运行的代码,必须时刻保持稳定,严禁直接 Push,只有经过测试的代码才能合并进来。dev(开发分支) :这是练兵场。大家日常开发集成的地方,新功能都在这里合并。feature/xxx(特性分支) :这是你的个人工作室。每个人拉出自己的分支(比如feature-shopping-cart),你在里面怎么写都不会影响到队友。hotfix/xxx(修复分支) :这是急救室。线上出 Bug 了,从这里切入,修完即走。
🏁 第一阶段:安营扎寨,正常开发
场景:产品经理给你派了个活,开发一个“购物车”功能。你不能直接在 dev 分支上写,否则你写一半代码没提交,队友的代码就拉取不了了。
操作步骤:
-
同步最新代码(好习惯):
bash
编辑
git checkout dev git pull origin dev -
创建并切换分支:
bash
编辑
# -b 表示创建并切换 git checkout -b feature-shopping-cart -
沉浸式写代码:
你新建了cart.js和style.css,写了一下午。 -
提交代码:
bash
编辑
git add . git commit -m "feat: 完成购物车列表页UI"
🚑 第二阶段:突发状况,Git Stash 救场
场景:正当你写到购物车逻辑的关键处(写了 logic.js,还没写完,全是 console.log),测试小姐姐突然跑过来说:“首页有个文字错误,很严重,马上修!”
你的现状:工作区是“脏”的(有未提交的修改)。如果直接切分支,Git 会报错,或者把这一堆半成品带过去,污染其他分支。强行 Commit 一个“未完成”的版本又很恶心,污染历史记录。
解决方案:Git Stash(暂存)
-
把现场“藏”起来:
bash
编辑
git stash终端提示:Saved working directory and index state...
此时,你的工作区瞬间变干净了,仿佛刚才什么都没发生过,回到了上次提交的状态。 -
切换分支去修 Bug:
bash
编辑
git checkout dev git checkout -b hotfix-typo -
修复并提交:
修改index.html,修复文字错误。bash
编辑
git add . git commit -m "fix: 修正首页文字错误" git push origin hotfix-typo(然后去网页上提一个 Merge Request 合并到 dev)
-
回到刚才的开发现场:
bash
编辑
git checkout feature-shopping-cart -
把“藏”起来的代码“放”出来:
bash
编辑
git stash pop刚才没写完的
logic.js又回来了,继续开发!
🔄 第三阶段:代码冲突,拒绝“蜘蛛网”
场景:你修完 Bug 回来继续写购物车,写了一天准备下班了。结果发现同事小王刚才提交了代码,他也修改了 cart.js。你需要把他的代码合进来。
小白做法:直接 git pull。
后果:git pull 本质上是 git fetch + git merge。默认的 Merge 操作可能会产生复杂的“蜘蛛网”提交记录(Merge Commit),让提交历史变得杂乱无章,后期排查问题非常痛苦。
专业做法:
-
先拉取远程更新(但不合并) :
bash
编辑
git fetch origin这步操作只是把远程的更新下载到你本地的
origin/dev指针上,不会动你当前的代码,非常安全。你可以先用git diff看看远程改了什么。 -
合并代码(保持线性历史) :
这里我们使用 Rebase(变基) 。它的作用是把你的提交“拿起来”,然后“垫”在小王的提交后面。bash
编辑
git rebase origin/dev- 如果有冲突:Git 会停下来告诉你哪里冲突了。你手动修改文件解决冲突 ->
git add .->git rebase --continue。 - 优点:你的提交历史是一条干净的直线,看起来就像你是基于最新的代码开发的一样,而不是分叉的网状结构。
- 如果有冲突:Git 会停下来告诉你哪里冲突了。你手动修改文件解决冲突 ->
🚀 第四阶段:大功告成,合并上线
场景:购物车功能终于写完了,代码也同步到了最新。现在要合并回 dev 分支。
-
切换到开发主分支:
bash
编辑
git checkout dev -
合并你的功能分支:
bash
编辑
git merge feature-shopping-cart注:在公司里,通常是在网页上提 Pull Request / Merge Request,审核通过后点合并按钮,原理是一样的。
-
推送到远程:
bash
编辑
git push origin dev -
清理战场(可选):
bash
编辑
git branch -d feature-shopping-cart
💡 核心命令速查表
为了方便记忆,我把今天用到的核心操作整理成了表格:
表格
| 场景 | 命令 | 作用 | 备注 |
|---|---|---|---|
| 被打断 | git stash | 暂存当前修改 | 这里的修改还没写完,不想 Commit |
| 恢复现场 | git stash pop | 恢复暂存的修改 | 继续刚才的工作 |
| 同步远程 | git fetch | 仅下载,不合并 | 安全,不会破坏当前代码 |
| 整理历史 | git rebase | 变基 | 让提交历史变成一条直线 |
| 合并分支 | git merge | 合并 | 用于将功能分支合入主分支 |
📌 总结
Git 不仅仅是几个命令的堆砌,更是一种工作流。
- 用 分支 隔离风险;
- 用 Stash 应对突发打断;
- 用 Fetch + Rebase 保持历史整洁;
- 用 Merge 完成最终交付。