拒绝做Git“蜘蛛网”制造者！从分支管理到Rebase，带你走一遍标准开发流

很多刚接触 Git 的同学，命令背得滚瓜烂熟：pull 是拉取，push 是推送，merge 是合并。但一旦到了真实的项目开发中，面对"写到一半被叫去修紧急 Bug"、"同事改了同一行代码"等突发状况，手里的命令就不知道怎么用了。

今天，我想结合自己日常的实战经验，模拟一个真实的电商项目开发场景，带你走一遍从功能开发 到紧急修复 ，再到代码合并的完整流程。这不仅仅是命令的堆砌，更是如何保持提交历史整洁、高效协作的"心法"。

在开始写代码前，先明确我们的"战场"。Git 的分支设计初衷就是为了解决多人协作互不干扰的问题。我们可以把分支想象成不同的平行宇宙：

main/master（主分支） ：这是圣殿。线上正在运行的代码，必须时刻保持稳定，严禁直接 Push，只有经过测试的代码才能合并进来。
dev（开发分支） ：这是练兵场。大家日常开发集成的地方，新功能都在这里合并。
feature/xxx（特性分支） ：这是你的个人工作室。每个人拉出自己的分支（比如 feature-shopping-cart），你在里面怎么写都不会影响到队友。
hotfix/xxx（修复分支） ：这是急救室。线上出 Bug 了，从这里切入，修完即走。

场景：产品经理给你派了个活，开发一个"购物车"功能。你不能直接在 dev 分支上写，否则你写一半代码没提交，队友的代码就拉取不了了。

操作步骤：

创建并切换分支：

bash

编辑

css 复制代码

# -b 表示创建并切换
git checkout -b feature-shopping-cart

提交代码：

bash

编辑

sql 复制代码

git add .
git commit -m "feat: 完成购物车列表页UI"

场景：正当你写到购物车逻辑的关键处（写了 logic.js，还没写完，全是 console.log），测试小姐姐突然跑过来说："首页有个文字错误，很严重，马上修！"

你的现状：工作区是"脏"的（有未提交的修改）。如果直接切分支，Git 会报错，或者把这一堆半成品带过去，污染其他分支。强行 Commit 一个"未完成"的版本又很恶心，污染历史记录。

解决方案：Git Stash（暂存）

把现场"藏"起来：

bash

编辑
复制代码
```
git stash
```
终端提示：Saved working directory and index state...

此时，你的工作区瞬间变干净了，仿佛刚才什么都没发生过，回到了上次提交的状态。
切换分支去修 Bug：

bash

编辑
css 复制代码
```
git checkout dev
git checkout -b hotfix-typo
```
修复并提交 ：

修改 index.html，修复文字错误。

bash

编辑
sql 复制代码
```
git add .
git commit -m "fix: 修正首页文字错误"
git push origin hotfix-typo
```
(然后去网页上提一个 Merge Request 合并到 dev)
回到刚才的开发现场：

bash

编辑
复制代码
```
git checkout feature-shopping-cart
```
把"藏"起来的代码"放"出来：

bash

编辑
perl 复制代码
```
git stash pop
```
刚才没写完的 logic.js 又回来了，继续开发！

场景：你修完 Bug 回来继续写购物车，写了一天准备下班了。结果发现同事小王刚才提交了代码，他也修改了 cart.js。你需要把他的代码合进来。

小白做法 ：直接 git pull。
后果：git pull 本质上是 git fetch + git merge。默认的 Merge 操作可能会产生复杂的"蜘蛛网"提交记录（Merge Commit），让提交历史变得杂乱无章，后期排查问题非常痛苦。

专业做法：

先拉取远程更新（但不合并） ：

bash

编辑
sql 复制代码
```
git fetch origin
```
这步操作只是把远程的更新下载到你本地的 origin/dev 指针上，不会动你当前的代码，非常安全。你可以先用 git diff 看看远程改了什么。
合并代码（保持线性历史） ：

这里我们使用 Rebase（变基） 。它的作用是把你的提交"拿起来"，然后"垫"在小王的提交后面。

bash

编辑
bash 复制代码
```
git rebase origin/dev
```
- 如果有冲突 ：Git 会停下来告诉你哪里冲突了。你手动修改文件解决冲突 -> git add . -> git rebase --continue。
- 优点：你的提交历史是一条干净的直线，看起来就像你是基于最新的代码开发的一样，而不是分叉的网状结构。

场景：购物车功能终于写完了，代码也同步到了最新。现在要合并回 dev 分支。

切换到开发主分支：

bash

编辑
复制代码
```
git checkout dev
```
合并你的功能分支：

bash

编辑
sql 复制代码
```
git merge feature-shopping-cart
```
注：在公司里，通常是在网页上提 Pull Request / Merge Request，审核通过后点合并按钮，原理是一样的。
推送到远程：

bash

编辑
perl 复制代码
```
git push origin dev
```
清理战场（可选）：

bash

编辑
复制代码
```
git branch -d feature-shopping-cart
```

为了方便记忆，我把今天用到的核心操作整理成了表格：

表格

Git 不仅仅是几个命令的堆砌，更是一种工作流。