几乎所有版本控制系统（VCS）都支持分支，但Git的分支功能堪称“杀手锏”✨！它轻量、快速，能让你随心所欲地创建分支、切换分支、合并分支，甚至一天合并好几次都不费劲～

对于初学者来说，掌握Git分支就像学会了“分身术”🧙‍♂️：同一时间能推进多个功能开发，还不用担心代码互相干扰。接下来咱们从基础到进阶，一步步解锁Git分支的全部技能！

第一部分：分支的本质 - 什么是Git分支？

⭐ 一、分支的本质 - 轻量级的“提交指针”

关键字：提交快照、指针、master分支、HEAD指针

要理解Git分支，得先回忆一个核心知识点：Git存储数据的方式不是“变更记录”，而是“快照”📸！每次提交，Git都会保存当前项目的完整快照，并创建一个“提交对象”。

趣味类比🚌：

把项目开发比作一趟公交车旅程——每次提交就是给当前的“乘客（代码）”拍一张合影（快照），提交对象就是这张合影的编号。而分支，就是贴在合影上的“标签”，比如“1.0版本路线”“新功能测试路线”。

1. 提交对象的构成

每个提交对象包含3样东西：

📁 指向项目快照的指针（通过SHA-1哈希值标识）
👤 作者信息、提交信息（就是你写的commit -m 内容）
👪 父提交指针（初始提交没有父指针，普通提交1个父指针，合并提交多个父指针）

2. 分支 = 可移动的指针

Git的分支本质上就是一个“轻量级指针”，指向某个提交对象。默认创建的分支叫

master

（现在很多项目改用main，但原理一样），它会随着你的每次提交自动“向前移动”。

查看当前分支（刚初始化的仓库） $g i t ini t$ git branch # 此时会显示 * master（* 表示当前所在分支）

3. HEAD指针：告诉你“当前在哪个分支”

Git里有个特殊指针叫

HEAD

，它永远指向你“当前正在工作的分支”🧭。比如你在master分支时，HEAD就指向master；切换到其他分支，HEAD就跟着切换。

初学者注意⚠️：

master分支不是“特殊分支”！它和你创建的其他分支没区别，只是git init默认创建它而已。就像公交车的“默认路线”，你完全可以改名字～

深度扩展🧠：

为什么Git分支这么快？因为它只创建一个41字节的文件（存储40位SHA-1哈希+换行），不用复制整个项目目录！而其他VCS创建分支可能要复制所有文件，大项目会等很久～

第二部分：基础操作 - 分支的创建、切换与删除

👋 二、基础操作 - 分支的“创建、切换、删除”三部曲

关键字：git branch、git checkout、git checkout -b、git branch -d

这是Git分支最常用的三个操作，记住命令格式+实际场景，就能轻松上手～

1. 创建分支：git branch [分支名]

创建一个新分支，指针指向当前所在的提交。

假设当前在master分支，创建名为testing的分支 $g i t b r an c h t es t in g$ git branch # 查看分支，会显示 master 和 testing（* 还在master） * master testing

2. 切换分支：git checkout [分支名]

切换到已存在的分支，同时HEAD指针会跟着移动到该分支。

切换到testing分支 $g i t c h ec k o u tt es t in g S w i t c h e d t o b r an c h^{'} t es t in g^{'}$ git branch # 现在 * 到testing了 master * testing

重要提醒❗️：

切换分支时，工作目录的文件会自动“回滚”到该分支最后一次提交的状态！如果有未提交的修改，Git会阻止切换（避免文件冲突），解决方法后续讲“暂存（stashing）”。

3. 创建+切换一步到位：git checkout -b [分支名]

这是最常用的快捷命令，相当于先git branch再git checkout。

创建并切换到iss53分支（比如用来开发编号53的需求） $ git checkout -b iss53 Switched to a new branch ‘iss53’ # 等价于： # git branch iss53 # git checkout iss53

4. 删除分支：git branch -d [分支名]

分支合并到主分支后，就可以删除了（避免分支过多混乱）。

假设iss53分支已合并到master，删除它 $git checkout master # 先回到master$ git branch -d iss53 Deleted branch iss53 (3a0874c).

复杂场景应用🌐：

如果分支还没合并就想删除（比如需求取消），用 -D 强制删除：git branch -D [分支名]。但要注意：强制删除会丢失该分支的所有提交，谨慎使用！

趣味场景🎬：

你在master分支（主线剧情）开发，突然接到一个紧急bug修复需求。用git checkout -b hotfix创建热修复分支（支线剧情），修复后合并回master，再删除hotfix分支，完美不影响主线～

第三部分：分支合并 - 把多个分支的代码合在一起

🤝 三、分支合并 - 让不同分支的代码“团聚”

关键字：git merge、快进合并（fast-forward）、三方合并、合并冲突

分支开发完成后（比如功能开发好、bug修复完），需要把代码合并回主分支（如master），这就是git merge的作用。

1. 快进合并（fast-forward）：简单直接的合并

如果被合并的分支是主分支的“直接后代”（没有分叉），Git会直接把主分支的指针“移动”到被合并分支的最新提交，这就是快进合并。

趣味类比🏃：

主分支master像一条直路，你创建的hotfix分支在master后面跟着跑，没有岔路。合并时，master直接“追”到hotfix的位置，不用处理任何冲突。

场景：hotfix分支修复完bug，合并回master $git checkout master # 回到主分支$ git merge hotfix # 合并hotfix分支 Updating f42c576..3a0874c Fast-forward # 快进合并成功 index.html | 2 ++ 1 file changed, 2 insertions(+)

2. 三方合并：处理分叉的情况

如果主分支和开发分支都有新提交（出现分叉），Git会做“三方合并”——找到两个分支的共同祖先提交，再把两个分支的修改合并成一个新的“合并提交”。

场景：iss53分支开发完功能，合并回master（master期间也有提交） $g i t c h ec k o u t ma s t er$ git merge iss53 Merge made by the ‘recursive’ strategy. # 三方合并成功 index.html | 1 + 1 file changed, 1 insertion(+)

3. 合并冲突：最常见的“小麻烦”

如果两个分支修改了

同一个文件的同一部分

，Git无法自动判断保留哪个，就会出现“合并冲突”。这时候需要手动解决！

合并时出现冲突的提示 $ git merge iss53 Auto-merging index.html CONFLICT (content): Merge conflict in index.html Automatic merge failed; fix conflicts and then commit the result.

冲突文件会被标记冲突内容，打开文件会看到：

<<<<<<< HEAD:index.html # 当前分支（master）的内容

contact : email.support@github.com

=======

please contact us at support@github.com

iss53:index.html # 被合并分支（iss53）的内容

解决冲突的步骤（初学者必看）：

打开冲突文件，找到<<<<<<<、=======、>>>>>>>标记的部分
手动修改内容（保留需要的代码，删除冲突标记）
用git add [冲突文件名] 标记为已解决
用git commit 提交（无需写-m，Git会自动生成合并提交信息）

解决冲突后提交 $g i t a dd in d e x . h t m l$ git commit # 直接回车，编辑提交信息后保存退出

进阶工具🧰：

如果冲突太多，用图形化工具更方便！运行git mergetool，Git会自动打开系统默认的合并工具（如VS Code、Beyond Compare），可视化解决冲突～

第四部分：分支管理 - 让分支井然有序

📋 四、分支管理 - 做个“分支整理大师”

关键字：git branch -v、—merged、—no-merged、分支命名规范

项目大了之后，分支会越来越多（比如feature/xxx、bugfix/xxx、hotfix/xxx），学会管理分支能避免混乱～

1. 查看分支详情：git branch -v

显示每个分支的最后一次提交信息（哈希值+提交说明）。

$ git branch -v iss53 93b412c fix javascript issue * master 7a98805 Merge branch ‘iss53’ testing 782fd34 add author list

2. 查看已合并/未合并分支

git branch —merged：查看已合并到当前分支的分支（可安全删除）
git branch —no-merged：查看未合并的分支（删除需谨慎）

查看已合并到master的分支 $git branch --merged iss53 * master # 查看未合并的分支$ git branch —no-merged testing

3. 分支命名规范（实践必备）

没有强制规范，但团队协作时建议统一，比如：

功能分支：feature/需求编号-功能名（如feature/53-footer）
bug修复分支：bugfix/ bug编号-描述（如bugfix/1328-stackoverflow）
热修复分支：hotfix/问题描述（如hotfix/email-error）
测试分支：test/功能名（如test/payment）

趣味类比📂：

分支命名就像给文件分类——按“功能/修复/测试”建文件夹，每个分支放在对应的文件夹下，团队成员一眼就知道这个分支是干嘛的，协作效率翻倍～

复杂场景🌐：

大型项目可能有“长期分支”（如master-稳定版、develop-开发版）和“短期分支”（如feature/bugfix-用完就删）。长期分支保持稳定，短期分支开发完成后合并到develop，再由develop合并到master发布。

第五部分：远程分支 - 团队协作必备

☁️ 五、远程分支 - 团队协作的“桥梁”

关键字：远程跟踪分支、git fetch、git push、git pull、跟踪分支

单人开发用本地分支就够了，但团队协作需要“远程仓库”（如GitHub、GitLab），远程分支就是连接本地和远程的桥梁～

1. 远程跟踪分支：[远程名]/[分支名]

克隆远程仓库后，Git会自动创建“远程跟踪分支”，比如origin/master（origin是远程仓库的默认名）。它是本地的“书签”，记录远程分支的最新状态，不能手动修改，会自动同步。

趣味类比📡：

远程跟踪分支就像你手机里的“朋友定位”——它告诉你朋友（远程分支）上次更新的位置，你刷新（fetch）后才会显示最新位置，但你不能直接移动朋友的位置～

2. 拉取远程更新：git fetch [远程名]

获取远程仓库的最新数据，但不合并到本地分支（安全，先看更新再决定）。

获取origin远程的所有更新 $git fetch origin # 此时origin/master会更新到远程最新状态 # 查看远程跟踪分支$ git branch -r # -r 表示remote（远程） origin/master origin/iss53

3. 推送本地分支到远程：git push [远程名] [本地分支名]

把本地分支的提交推送到远程仓库，让团队成员看到。

把本地的serverfix分支推送到origin远程 $ git push origin serverfix # 远程会创建同名的serverfix分支

初学者避坑⚠️：

推送前最好先git fetch + git merge（或git pull），避免远程分支已有更新导致冲突，推送失败～

4. 拉取并合并：git pull [远程名] [分支名]

相当于git fetch + git merge（快捷命令），适合快速同步远程更新。

拉取origin远程的master分支，合并到本地当前分支 $ git pull origin master

5. 跟踪分支：让本地分支和远程分支关联

关联后，git pull/push不用写远程名和分支名，Git会自动识别。

方法1：克隆后默认master跟踪origin/master # 方法2：手动关联本地分支和远程分支 $git checkout -b serverfix origin/serverfix # 或简写（如果本地分支名和远程一致）$ git checkout serverfix # 方法3：已有本地分支，手动设置关联 $ git branch -u origin/serverfix

团队协作场景🌐：

比如你和同事一起开发serverfix功能——同事推送了更新到origin/serverfix，你用git pull origin serverfix拉取更新，解决冲突后再推送自己的修改，这样就能实时同步协作啦～

第六部分：变基（Rebase） - 让提交历史更“干净”

🔄 六、变基（Rebase） - 提交历史的“美颜滤镜”

关键字：git rebase、变基原理、变基vs合并、变基禁忌

除了merge，Git还有一种合并分支的方式——变基（rebase）。它的核心作用是“改写提交历史”，让历史记录更线性、更干净～

1. 变基的原理：“重播”提交

变基就是把一个分支的所有提交，按顺序“重播”到另一个分支的最新提交上，相当于重新创建一系列新的提交（哈希值会变）。

趣味类比🎬：

合并（merge）像“剪辑电影”——把两条剧情线（分支）剪在一起，保留所有原始镜头（提交）；变基（rebase）像“重拍电影”——把支线剧情（如iss53分支）的镜头，按顺序拍到主线剧情（master）的后面，让剧情看起来是“一次性完成”的。

2. 基本变基命令：git rebase [目标分支]

把当前分支的提交，变基到目标分支上。

场景：当前在iss53分支，把它的提交变基到master分支 $g i t c h ec k o u t i ss 53$ git rebase master # 完成后，iss53的提交都在master最新提交的后面 # 再切换到master，做快进合并 $g i t c h ec k o u t ma s t er$ git merge iss53

3. 变基vs合并：各有优劣

合并（merge）：保留原始提交历史，能看到分支分叉的过程，但历史可能杂乱。
变基（rebase）：历史记录线性干净，容易追溯，但改写了提交历史（哈希值变了）。

选择建议🧠：

✅ 本地分支（未推送远程）：用rebase，让自己的提交历史更干净，方便后续代码审查。 ❌ 已推送远程的分支：绝对不能rebase！因为别人可能已经基于你的旧提交开发，改写历史会导致团队代码冲突、提交重复，场面会非常混乱～

4. 变基的禁忌：不要变基公共分支

这是Git使用的“铁律”！记住：

不要变基已经推送到远程仓库、被其他人使用的分支

。

后果警示❗️：

如果你变基了远程分支并强制推送（git push —force），别人拉取后会发现提交历史错乱，合并时会出现大量重复提交，排查问题时会崩溃～

5. 变基冲突的解决

变基过程中也可能出现冲突，解决方式和合并冲突类似：

变基时出现冲突，Git会暂停 $git rebase master Auto-merging index.html CONFLICT (content): Merge conflict in index.html # 1. 打开文件解决冲突 # 2. 标记为已解决$ git add index.html # 3. 继续变基（重播下一个提交） $ git rebase —continue # （如果想放弃变基，运行 git rebase —abort）

第七部分：实战场景 - 分支 workflow 示例

🚀 七、实战场景 - 真实项目的分支使用流程

关键字：功能开发、热修复、分支流程、团队协作

结合前面的知识点，我们模拟一个真实项目的分支使用流程，初学者可以直接套用～

场景：电商网站开发，需求是“添加支付功能”+“修复登录bug”

1. 准备工作：克隆远程仓库，创建开发分支

克隆远程仓库（假设远程仓库地址是git.ourcompany.com/ecommerce.git）

$g i t c l o n e g i t . o u r co m p an y . co m / eco mm er ce . g i t$ cd ecommerce

创建并切换到feature/payment分支（开发支付功能）

$ git checkout -b feature/payment 2. 2. 开发支付功能，多次提交

编写代码后提交

$g i t a dd .$ git commit -m ‘添加支付宝支付接口’ $g i t a dd .$ git commit -m ‘完善支付回调逻辑’ 3. 3. 接到紧急bug：登录时密码错误不提示，需要热修复

切换回master分支（确保代码干净，无未提交修改）

$ git checkout master

创建热修复分支

$ git checkout -b hotfix/login-alert

修复bug后提交

$g i t a dd .$ git commit -m ‘修复登录密码错误无提示bug’

合并回master分支

$g i t c h ec k o u t ma s t er$ git merge hotfix/login-alert

推送master到远程（发布修复）

$ git push origin master

删除热修复分支

$ git branch -d hotfix/login-alert 4. 4. 把master的热修复同步到支付功能分支

切换回feature/payment分支

$ git checkout feature/payment

变基到master（同步热修复代码，保持历史干净）

$ git rebase master

（如果有冲突，解决后git add + git rebase —continue）

5. 支付功能开发完成，推送到远程，等待审核 $ git push origin feature/payment

此时可以在GitLab/GitHub上创建合并请求（MR/PR），让团队审核代码

6. 审核通过后，合并到master并发布

（管理员操作）合并feature/payment到master

$g i t c h ec k o u t ma s t er$ git merge feature/payment $ git push origin master

删除本地和远程的功能分支

$g i t b r an c h - df e a t u r e / p a y m e n t$ git push origin —delete feature/payment

流程总结🗺️：

这就是典型的“功能分支 workflow”——主分支（master）保持稳定，所有开发在功能分支/热修复分支进行，完成后合并回主分支，既安全又高效～

复杂项目扩展🌐：

大型项目可能会有更多分支，比如develop（开发主分支）、release（发布分支）、bugfix（普通bug修复分支）等，但核心逻辑和上面一致——“分支隔离开发，合并统一发布”。

总结与交付物提议

🎯 八、总结 - Git分支核心技能图谱

Git分支是开发的“必备技能”，掌握这些核心点就能应对99%的场景：

💡 分支本质：轻量级指针，指向提交快照
💡 基础操作：git branch/git checkout/git checkout -b/git branch -d
💡 合并分支：git merge（快进/三方合并）+ 解决冲突
💡 团队协作：远程分支+git fetch/git push/git pull+跟踪分支
💡 进阶技能：git rebase（本地分支用，公共分支禁用）

要不要我帮你整理一份

Git分支常用命令速查表

？包含命令格式、场景说明和注意事项，打印出来就能随时查阅，帮你快速巩固这些知识点～

description	几乎所有版本控制系统（VCS）都支持分支，但Git的分支功能堪称“杀手锏”✨！它轻量、快速，能让你随心所欲地创建分支、切换分支、合并分支，甚至一天合并好几次都不费劲～对于初学者来
tags	git

嵌入式开发之路

探索

📚 第Git分支 - 玩转分支，开发效率翻倍🚀