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

0 阅读5分钟

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

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

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

🌿 分支管理:构建你的“平行宇宙”

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

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

🏁 第一阶段:安营扎寨,正常开发

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

操作步骤

  1. 同步最新代码(好习惯):

    bash

    编辑

    git checkout dev
    git pull origin dev
    
  2. 创建并切换分支

    bash

    编辑

    # -b 表示创建并切换
    git checkout -b feature-shopping-cart
    
  3. 沉浸式写代码
    你新建了 cart.js 和 style.css,写了一下午。

  4. 提交代码

    bash

    编辑

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

🚑 第二阶段:突发状况,Git Stash 救场

场景:正当你写到购物车逻辑的关键处(写了 logic.js,还没写完,全是 console.log),测试小姐姐突然跑过来说:“首页有个文字错误,很严重,马上修!”

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

解决方案:Git Stash(暂存)

  1. 把现场“藏”起来

    bash

    编辑

    git stash
    

    终端提示:Saved working directory and index state...
    此时,你的工作区瞬间变干净了,仿佛刚才什么都没发生过,回到了上次提交的状态。

  2. 切换分支去修 Bug

    bash

    编辑

    git checkout dev
    git checkout -b hotfix-typo
    
  3. 修复并提交
    修改 index.html,修复文字错误。

    bash

    编辑

    git add .
    git commit -m "fix: 修正首页文字错误"
    git push origin hotfix-typo
    

    (然后去网页上提一个 Merge Request 合并到 dev)

  4. 回到刚才的开发现场

    bash

    编辑

    git checkout feature-shopping-cart
    
  5. 把“藏”起来的代码“放”出来

    bash

    编辑

    git stash pop
    

    刚才没写完的 logic.js 又回来了,继续开发!

🔄 第三阶段:代码冲突,拒绝“蜘蛛网”

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

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

专业做法

  1. 先拉取远程更新(但不合并)

    bash

    编辑

    git fetch origin
    

    这步操作只是把远程的更新下载到你本地的 origin/dev 指针上,不会动你当前的代码,非常安全。你可以先用 git diff 看看远程改了什么。

  2. 合并代码(保持线性历史)
    这里我们使用 Rebase(变基) 。它的作用是把你的提交“拿起来”,然后“垫”在小王的提交后面。

    bash

    编辑

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

🚀 第四阶段:大功告成,合并上线

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

  1. 切换到开发主分支

    bash

    编辑

    git checkout dev
    
  2. 合并你的功能分支

    bash

    编辑

    git merge feature-shopping-cart
    

    注:在公司里,通常是在网页上提 Pull Request / Merge Request,审核通过后点合并按钮,原理是一样的。

  3. 推送到远程

    bash

    编辑

    git push origin dev
    
  4. 清理战场(可选):

    bash

    编辑

    git branch -d feature-shopping-cart
    

💡 核心命令速查表

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

表格

场景命令作用备注
被打断git stash暂存当前修改这里的修改还没写完,不想 Commit
恢复现场git stash pop恢复暂存的修改继续刚才的工作
同步远程git fetch仅下载,不合并安全,不会破坏当前代码
整理历史git rebase变基让提交历史变成一条直线
合并分支git merge合并用于将功能分支合入主分支

📌 总结

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

  • 用 分支 隔离风险;
  • 用 Stash 应对突发打断;
  • 用 Fetch + Rebase 保持历史整洁;
  • 用 Merge 完成最终交付。