Git 完全指南（二）：分支管理

lingran__2026-09-03 17:54

目录

引言：

1~>理解分支

[1.1 什么是分支？](#1.1 什么是分支？)

[1.2 时间线与 master 分支](#1.2 时间线与 master 分支)

[1.3 HEAD 指针的真相](#1.3 HEAD 指针的真相)

[1.4 分支的价值](#1.4 分支的价值)

[2~>创建分支（git branch）](#2~>创建分支（git branch）)

[2.1 查看与创建分支](#2.1 查看与创建分支)

[2.2 分支的底层原理](#2.2 分支的底层原理)

[3~>切换分支（git checkout）](#3~>切换分支（git checkout）)

[3.1 切换到 dev 分支](#3.1 切换到 dev 分支)

[3.2 分支的独立性](#3.2 分支的独立性)

[3.3 分支指针的差异](#3.3 分支指针的差异)

[4~>合并分支（git merge）](#4~>合并分支（git merge）)

[4.1 Fast-forward 合并](#4.1 Fast-forward 合并)

[5~>删除分支（git branch -d）](#5~>删除分支（git branch -d）)

[5.1 删除规则](#5.1 删除规则)

[5.2 分支生命周期总结](#5.2 分支生命周期总结)

6~>合并冲突

[6.1 快速创建并切换分支](#6.1 快速创建并切换分支)

[6.2 制造冲突场景](#6.2 制造冲突场景)

[6.3 冲突发生](#6.3 冲突发生)

[6.4 解决冲突](#6.4 解决冲突)

[6.5 查看合并历史](#6.5 查看合并历史)

[6.6 清理分支](#6.6 清理分支)

7~>合并模式

[7.1 Fast-forward 模式的隐患](#7.1 Fast-forward 模式的隐患)

[7.2 非 Fast-forward 模式（--no-ff）](#7.2 非 Fast-forward 模式（--no-ff）)

[7.3 对比两种模式的历史记录](#7.3 对比两种模式的历史记录)

[7.4 模式选择建议](#7.4 模式选择建议)

8~>分支策略

[8.1 经典分支模型](#8.1 经典分支模型)

[9~>bug分支（git stash）](#9~>bug分支（git stash）)

[9.1 场景引入](#9.1 场景引入)

[9.2 错误示范：直接切换分支](#9.2 错误示范：直接切换分支)

[9.3 正确做法：git stash 储藏工作区](#9.3 正确做法：git stash 储藏工作区)

[9.4 切换到 master 修复 Bug](#9.4 切换到 master 修复 Bug)

[9.5 恢复储藏的工作区](#9.5 恢复储藏的工作区)

[9.6 进阶：合并 Bug 修复到开发分支](#9.6 进阶：合并 Bug 修复到开发分支)

[9.7 清理分支](#9.7 清理分支)

[10~>强制删除分支（git branch -D）](#10~>强制删除分支（git branch -D）)

[10.1 场景引入](#10.1 场景引入)

[10.2 普通删除失败](#10.2 普通删除失败)

[10.3 强制删除](#10.3 强制删除)

[10.4 删除参数对比](#10.4 删除参数对比)

[10.5 实际工作流总结](#10.5 实际工作流总结)

结语：

引言：

这是《Git 完全指南》系列的第二篇。

在系列第一篇中，我们掌握了 Git 的本地仓库操作------初始化、添加、提交、回退、撤销。这些操作都在单一的时间线上进行，如同在一条笔直的公路上行驶。

但真实的软件开发从来不是单线程的。当多人协作、多任务并行、紧急 Bug 突袭时，我们需要分支这把利器。

分支是 Git 的杀手级特性之一。它让代码的演化从"单行道"变成"立交桥"：主路保持稳定通行，辅路各自施工，完工后再汇入主路。这种"平行宇宙"式的开发模式，既保证了代码安全，又极大提升了团队效率。

本系列规划：

篇章 内容 状态
（一）本地仓库基础操作 安装配置、核心概念、文件操作、版本回退 已发布
（二）分支管理 创建切换、合并冲突、分支策略、Bug 分支 本文
（三）远程操作与团队协作 远程仓库、推送拉取、多人工作流 待发布
（四）标签管理与版本发布 标签操作、版本控制、发布流程 待发布
（五）企业级开发模型 Git Flow、GitHub Flow、CI/CD 集成 待发布

本文将从分支的底层指针机制讲起，逐步深入到合并冲突解决、企业分支策略、git stash 现场保护等实战技巧。无论你是独立开发者还是团队成员，理解分支管理都是迈向高效协作的关键一步。

🎯 适合人群：已掌握 Git 基础操作，希望系统学习分支管理的开发者

💻 前置知识 ：建议先阅读《Git 完全指南（一）：本地仓库基础操作》------Git 完全指南（一）：本地仓库基础操作-CSDN博客

1~>理解分支

从本章开始，我们将进入 Git 的杀手级功能之一------分支管理。（注意是"之一"，后续还有远程协作、标签管理等诸多利器等待解锁。）

1.1 什么是分支？

分支的概念，可以用科幻电影中的平行宇宙来理解：

假设存在两个平行宇宙：宇宙 A 中的你正在埋头学习 C++，宇宙 B 中的你正在钻研 Java。两个宇宙互不干扰，各自发展。但在某个关键时刻，两个宇宙突然合并------于是，你既精通了 C++，又掌握了 Java！

在 Git 中，分支就是代码的平行宇宙。 你可以从主线路分离出一条支线，独立开发新功能或修复 Bug，完成后再将支线合并回主线。整个过程安全、高效，互不干扰。

1.2 时间线与 master 分支

在版本回退章节中，我们知道 Git 将每次提交串联成一条时间线。这条时间线，本质上就是一个分支。

截至目前，我们的仓库只有一条时间线------这就是主分支（master branch）。

1.3 HEAD 指针的真相

这里需要纠正一个常见误解：HEAD 严格来说并不直接指向提交，而是指向当前分支。

复制代码 
┌─────────┐      ┌─────────┐      ┌─────────┐
│  HEAD   │ ──→ │  master │ ──→ │ commit  │
│ (指针)   │      │ (分支)  │      │ (提交)  │
└─────────┘      └─────────┘      └─────────┘
         ↑
    HEAD 指向 master，
    master 指向最新提交

每次提交时，master 分支向前移动一步，时间线不断延长。而 HEAD 只需始终指向 master，就能代表"当前所在位置"。

1.4 分支的价值

master 作为主分支，承载着项目的稳定代码。在此基础上，我们可以：

操作 场景
创建分支 开发新功能、修复 Bug、实验性重构
切换分支 在不同任务间灵活跳转
合并分支 将完成的工作整合回主线

这种"主线稳定、支线开发、最终合并"的模式，是现代软件工程的标准实践，也是 Git 分支管理的核心价值。

2~>创建分支（git branch）

Git 支持查看现有分支或创建新分支。我们来创建第一个自己的分支 dev。

2.1 查看与创建分支

bash 复制代码 
# 查看当前所有本地分支
[root@VM-0-2-centos gitcode]# git branch
* master

# 创建 dev 分支
[root@VM-0-2-centos gitcode]# git branch dev

# 再次查看分支列表
[root@VM-0-2-centos gitcode]# git branch
  dev
* master

输出解读：

标记 含义
* HEAD 指针当前指向的分支，即工作分支
master 主分支，默认创建
dev 新创建的分支

💡 注意 ：* 表示当前工作分支。HEAD 不一定指向 master，它指向哪个分支，我们的 add、commit 操作就作用于哪个分支。

2.2 分支的底层原理

创建分支后，Git 实际上新建了一个名为 dev 的指针。查看 .git/refs/heads 目录：

bash 复制代码 
[root@VM-0-2-centos gitcode]# ls .git/refs/heads
dev  master

[root@VM-0-2-centos gitcode]# cat .git/refs/heads/master
3f5d6ac9667f8cbc6f8ebf140b8ce7aab429d8c9

[root@VM-0-2-centos gitcode]# cat .git/refs/heads/dev
3f5d6ac9667f8cbc6f8ebf140b8ce7aab429d8c9

发现 ：dev 和 master 指向相同的 commit ID。这是因为 dev 分支是基于最新一次提交创建出来的，初始时两者指向同一位置。

复制代码 
创建分支前：
master ──→ commit A
HEAD  ──→ master

创建 dev 分支后：
master ──→ commit A
dev    ──→ commit A
HEAD   ──→ master

3~>切换分支（git checkout）

3.1 切换到 dev 分支

使用 git checkout 命令切换分支（注意：这里不需要 --，与撤销工作区修改的用法区分）：

bash 复制代码 
[root@VM-0-2-centos gitcode]# git checkout dev
Switched to branch 'dev'

[root@VM-0-2-centos gitcode]# git branch
* dev
  master

[root@VM-0-2-centos gitcode]# cat .git/HEAD
ref: refs/heads/dev

验证 ：HEAD 已指向 dev，表示成功切换到 dev 分支。

3.2 分支的独立性

两个分支在合并前，操作互不影响。验证如下：

bash 复制代码 
# 确认当前在 dev 分支
[root@VM-0-2-centos gitcode]# git branch
* dev
  master

# 在 dev 分支创建文件并提交
[root@VM-0-2-centos gitcode]# touch test1
[root@VM-0-2-centos gitcode]# git add test1
[root@VM-0-2-centos gitcode]# git commit -m "add test1"
[dev 322f05e] add test1
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 test1

[root@VM-0-2-centos gitcode]# git status
# On branch dev
nothing to commit, working directory clean

[root@VM-0-2-centos gitcode]# ls
test1

# 切换回 master 分支
[root@VM-0-2-centos gitcode]# git checkout master
Switched to branch 'master'

[root@VM-0-2-centos gitcode]# ls
[root@VM-0-2-centos gitcode]# git branch
  dev
* master

现象 ：test1 文件"消失"了！这是因为 master 分支上没有 test1 文件。

3.3 分支指针的差异

bash 复制代码 
[root@VM-0-2-centos gitcode]# cat .git/refs/heads/master
3f5d6ac9667f8cbc6f8ebf140b8ce7aab429d8c9

[root@VM-0-2-centos gitcode]# cat .git/refs/heads/dev
322f05e3c052a5009a97546ba43fbcd282aa3052

结论 ：dev 分支前进了一步，而 master 停留在原地。HEAD 指向 master 时，自然看不到 dev 上的新提交。

复制代码 
dev 分支提交后：
master ──→ commit A
dev    ──→ commit B (add test1)
HEAD   ──→ master

切换到 dev：
master ──→ commit A
dev    ──→ commit B
HEAD   ──→ dev  ← 可以看到 test1

4~>合并分支（git merge）

为了让 master 分支看到 dev 的新提交，需要将 dev 合并到 master。

4.1 Fast-forward 合并

bash 复制代码 
# 确保当前在 master 分支
[root@VM-0-2-centos gitcode]# git merge dev
Updating 3f5d6ac..322f05e
Fast-forward
 test1 | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 test1

[root@VM-0-2-centos gitcode]# ls
test1

Fast-forward（快进模式） ：直接把 master 指针指向 dev 的当前提交，合并速度极快。

合并后验证：

bash 复制代码 
[root@VM-0-2-centos gitcode]# cat .git/refs/heads/master
322f05e3c052a5009a97546ba43fbcd282aa3052

[root@VM-0-2-centos gitcode]# cat .git/refs/heads/dev
322f05e3c052a5009a97546ba43fbcd282aa3052

此时 master 和 dev 指向同一提交。

复制代码 
合并前：
master ──→ commit A
dev    ──→ commit B
HEAD   ──→ master

Fast-forward 合并后：
master ──→ commit B
dev    ──→ commit B
HEAD   ──→ master

5~>删除分支（git branch -d）

合并完成后，dev 分支的历史使命完成，可以删除。

5.1 删除规则

不能删除当前所在分支：

bash 复制代码 
[root@VM-0-2-centos gitcode]# git branch
* dev
  master

[root@VM-0-2-centos gitcode]# git branch -d dev
error: Cannot delete the branch 'dev' which you are currently on.

切换到其他分支后再删除：

bash 复制代码 
[root@VM-0-2-centos gitcode]# git branch
  dev
* master

[root@VM-0-2-centos gitcode]# git branch -d dev
Deleted branch dev (was 322f05e).

[root@VM-0-2-centos gitcode]# git branch
* master

此时的状态如图如下所⽰。

5.2 分支生命周期总结

复制代码 
创建分支 → 开发工作 → 合并分支 → 删除分支
   ↑___________________________________↓

Git 的设计哲学 ：创建、合并、删除分支都非常轻量快速。Git 鼓励你频繁使用分支完成独立任务，合并后再清理，既保证主分支稳定，又确保开发过程安全。

6~>合并冲突

6.1 快速创建并切换分支

实际开发中，合并并非总是一帆风顺。先介绍一个便捷命令：

bash 复制代码 
git checkout -b dev1    # 一步完成：创建 dev1 分支并切换过去

等价于：

bash 复制代码 
git branch dev1
git checkout dev1

6.2 制造冲突场景

bash 复制代码 
# 创建并切换到 dev1 分支
[root@VM-0-2-centos gitcode]# git checkout -b dev1
Switched to a new branch 'dev1'

# 在 dev1 修改 test1
[root@VM-0-2-centos gitcode]# echo "in dev1" > test1
[root@VM-0-2-centos gitcode]# cat test1
in dev1

[root@VM-0-2-centos gitcode]# git add .
[root@VM-0-2-centos gitcode]# git commit -m "work in dev1"
[dev1 b1c7d59] work in dev1
 1 file changed, 1 insertion(+)

# 切换回 master，修改同一文件
[root@VM-0-2-centos gitcode]# git checkout master
Switched to branch 'master'

[root@VM-0-2-centos gitcode]# echo "in master" > test1
[root@VM-0-2-centos gitcode]# cat test1
in master

[root@VM-0-2-centos gitcode]# git add test1
[root@VM-0-2-centos gitcode]# git commit -m "work in master"
[master b337aa5] work in master
 1 file changed, 1 insertion(+)

此时分支状态：

复制代码 
master ──→ ... ──→ commit M (修改 test1 为 "in master")
                  ↑
dev1   ──→ ... ──→ commit D (修改 test1 为 "in dev1")

6.3 冲突发生

bash 复制代码 
[root@VM-0-2-centos gitcode]# git merge dev1
Auto-merging test1
CONFLICT (content): Merge conflict in test1
Automatic merge failed; fix conflicts and then commit the result.

冲突原因：两个分支对同一文件的同一位置做了不同修改，Git 无法自动判断哪个正确。

6.4 解决冲突

查看冲突文件：

bash 复制代码 
[root@VM-0-2-centos gitcode]# cat test1
<<<<<<< HEAD
in master
=======
in dev1
>>>>>>> dev1

冲突标记解析：

标记 含义
<<<<<<< HEAD 当前分支（master）的内容开始
======= 分隔线
>>>>>>> dev1 合并分支（dev1）的内容结束

手动解决：编辑文件，保留需要的内容，删除冲突标记：

bash 复制代码 
[root@VM-0-2-centos gitcode]# nano test1
[root@VM-0-2-centos gitcode]# cat test1
in dev1

重新提交 （必须执行，否则冲突未真正解决）：

bash 复制代码 
[root@VM-0-2-centos gitcode]# git add test1
[root@VM-0-2-centos gitcode]# git commit -m "merge dev1"
[master 06b37e0] merge dev1

6.5 查看合并历史

带参数的git log可以看到分支的合并情况

bash 复制代码 
[root@VM-0-2-centos gitcode]# git log --graph --pretty=oneline --abbrev-commit
*   06b37e0 merge dev1
|\  
| * fee9bca work in dev1
* | 432e388 work in master
|/  
* ab938e5 prev

图形解读：

  • * 表示提交节点
  • |\ 和 |/ 表示分支与合并

6.6 清理分支

bash 复制代码 
[root@VM-0-2-centos gitcode]# git branch -d dev1
Deleted branch dev1 (was fee9bca).

7~>合并模式

7.1 Fast-forward 模式的隐患

默认情况下，Git 优先使用 Fast-forward 模式合并。这种模式的缺点是：删除分支后，历史记录中看不到分支合并的痕迹。我就不知道这个ABC是master分支自己commit还是别的分支合并合出来的

复制代码 
Fast-forward 合并：
master ──→ A ──→ B ──→ C
                         ↑
                        dev (已删除，历史无痕迹)

7.2 非 Fast-forward 模式（--no-ff）

--no-ff 参数，表式禁用 Fast forward 模式。禁⽤ Fast forward 模式后合并会创建⼀个新的 commit ，所以加上 -m 参数，把描述写进去。

强制禁用 Fast-forward，合并时会生成一个新的 commit，保留分支历史：

bash 复制代码 
# 创建并切换到 dev 分支
[root@VM-0-2-centos gitcode]# git checkout -b dev
Switched to a new branch 'dev'

# 在 dev 上工作
[root@VM-0-2-centos gitcode]# touch test2
[root@VM-0-2-centos gitcode]# git add .
[root@VM-0-2-centos gitcode]# git commit -m "add test2"
[dev 4c7523b] add test2

# 切换回 master
[root@VM-0-2-centos gitcode]# git checkout master

# 使用 --no-ff 合并
[root@VM-0-2-centos gitcode]# git merge --no-ff -m "merge dev with no-ff" dev
Merge made by the 'recursive' strategy.
 test2 | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 test2

7.3 对比两种模式的历史记录

bash 复制代码 
[root@VM-0-2-centos gitcode]# git log --graph --pretty=oneline --abbrev-commit
*   d0e3791 merge dev with no-ff
|\  
| * 4c7523b add test2
|/

清晰可见 ：即使删除 dev 分支，历史记录中仍然保留"曾经从 dev 分支合并"的信息。

7.4 模式选择建议

场景 推荐模式 原因
临时分支、小改动 Fast-forward 历史简洁，无冗余
功能开发、版本迭代 --no-ff 保留分支历史，便于追溯
团队协作、生产环境 --no-ff 代码审查、回滚更安全

8~>分支策略

在实际开发中，分支管理应遵循以下基本原则：

8.1 经典分支模型

分支 稳定性 用途
master ⭐⭐⭐ 极高 仅用于发布新版本，平时不直接开发
dev ⭐⭐ 开发中 日常开发的主战场，功能集成后合并到 master
个人分支 ⭐ 临时 每个开发者在 dev 基础上创建自己的功能分支

工作流程：

复制代码 
1. 从 dev 创建个人功能分支
        ↓
2. 在个人分支上开发
        ↓
3. 开发完成，合并到 dev
        ↓
4. 测试通过，dev 合并到 master
        ↓
5. 在 master 上发布新版本

团队协作示意图：

核心思想 ：master 保持稳定可发布，dev 承担集成测试，个人分支自由开发互不干扰。这是 Git 支持多人协作开发的基石。

9~>bug分支（git stash）

9.1 场景引入

假设你正在 dev 分支上开发新功能，代码写到一半，突然接到通知：master 分支上有紧急 Bug 需要立即修复！

问题：工作区的代码还没完成，无法提交，怎么办？

9.2 错误示范：直接切换分支

复制代码 
# dev 分支上有未提交的修改
[root@VM-0-2-centos gitcode]# echo "wahaha" > test2
[root@VM-0-2-centos gitcode]# git checkout master
M	test2
Switched to branch 'master'

[root@VM-0-2-centos gitcode]# cat test2
wahaha

危险！ M test2 表示修改被携带到了 master 分支 ，这会污染主分支。虽然切回 dev 后 master 会恢复，但这种做法极不规范。

9.3 正确做法：git stash 储藏工作区

git stash 将当前工作区的修改临时储藏，使工作区恢复干净状态：

复制代码 
# 确认当前有未提交的修改
[root@VM-0-2-centos gitcode]# echo "ok" > test2
[root@VM-0-2-centos gitcode]# git status
# On branch dev
# Changes not staged for commit:
#	modified:   test2
#

# 储藏修改
[root@VM-0-2-centos gitcode]# git stash
Saved working directory and index state WIP on dev: 36bce97 no
HEAD is now at 36bce97 no

# 工作区已干净
[root@VM-0-2-centos gitcode]# git status
# On branch dev
nothing to commit, working directory clean

注意 ：git stash 只储藏已被 Git 跟踪的文件 。新建但未 add 的文件不会被储藏，需特别注意。

9.4 切换到 master 修复 Bug

复制代码 
[root@VM-0-2-centos gitcode]# git checkout master
Switched to branch 'master'

# 创建 bug 修复分支（推荐做法）
[root@VM-0-2-centos gitcode]# git checkout -b bug-fix
# ... 修复 bug ...
[root@VM-0-2-centos gitcode]# git add .
[root@VM-0-2-centos gitcode]# git commit -m "fix critical bug"
[root@VM-0-2-centos gitcode]# git checkout master
[root@VM-0-2-centos gitcode]# git merge --no-ff -m "merge bug fix" bug-fix
[root@VM-0-2-centos gitcode]# git branch -d bug-fix

9.5 恢复储藏的工作区

修复完 Bug 后，回到 dev 分支恢复现场：

bash 复制代码 
[root@VM-0-2-centos gitcode]# git checkout dev
Switched to branch 'dev'

# 查看储藏列表
[root@VM-0-2-centos gitcode]# git stash list
stash@{0}: WIP on dev: 36bce97 no

# 恢复并删除储藏
[root@VM-0-2-centos gitcode]# git stash pop
# On branch dev
# Changes not staged for commit:
#	modified:   test2
#
Dropped refs/stash@{0} (8576d215efea19921173ab33f76a85e306f0dbc2)

[root@VM-0-2-centos gitcode]# cat test2
ok

stash 命令速查：

命令 作用
git stash 储藏当前工作区和暂存区
git stash list 查看所有储藏记录
git stash pop 恢复最近一次储藏，并删除
git stash apply 恢复储藏，但保留记录
git stash drop 删除指定储藏
git stash apply stash@{n} 恢复指定的某次储藏

9.6 进阶：合并 Bug 修复到开发分支

问题 ：master 上的 Bug 修复，需要同步到 dev 分支吗？

最佳实践 ：在 dev 分支上先合并 master，解决冲突并测试，再让 master 合并 dev。这样避免在 master 上直接解决冲突，降低风险。

bash 复制代码 
# 切换到 dev，先合并 master 的更新
[root@VM-0-2-centos gitcode]# git checkout dev
[root@VM-0-2-centos gitcode]# git merge --no-ff -m "merge master" master

# 如果有冲突，在 dev 上解决
Auto-merging test2
CONFLICT (content): Merge conflict in test2

[root@VM-0-2-centos gitcode]# cat test2
<<<<<<< HEAD
ok
=======
no
>>>>>>> master

[root@VM-0-2-centos gitcode]# nano test2    # 手动解决冲突
[root@VM-0-2-centos gitcode]# git add .
[root@VM-0-2-centos gitcode]# git commit -m "fix bug"

# 再切换回 master 合并 dev（此时无冲突，安全）
[root@VM-0-2-centos gitcode]# git checkout master
[root@VM-0-2-centos gitcode]# git merge --no-ff -m "merge dev" dev
Already up-to-date!

合并后的分支历史：

bash 复制代码 
[root@VM-0-2-centos gitcode]# git log --graph --pretty=oneline --abbrev-commit
*   0e5ee6b merge dev
|\  
| *   b56946d fix bug
| |\  
| |/

下面这种直接合并到master是不好的，因为无法保证能一次性解决冲突

9.7 清理分支

功能完成后，删除无用分支：

bash 复制代码 
[root@VM-0-2-centos gitcode]# git branch
  dev
* master

[root@VM-0-2-centos gitcode]# git branch -d dev
Deleted branch dev (was b56946d).

10~>强制删除分支（git branch -D）

10.1 场景引入

开发新功能时，通常创建 feature 分支进行实验性开发：

bash 复制代码 
git checkout -b feature-x    # 创建功能分支
# ... 开发中 ...
git add .
git commit -m "feature x"

但如果开发到一半，产品经理突然叫停该功能，这个 feature 分支需要立即销毁。

10.2 普通删除失败

cpp 复制代码 
[root@VM-0-2-centos gitcode]# git branch -d dev
error: The branch 'dev' is not fully merged.
If you are sure you want to delete it, run 'git branch -D dev'.

原因：Git 检测到该分支的提交尚未合并到其他分支，出于保护机制拒绝删除。

10.3 强制删除

使用 -D（大写）参数强制删除：

bash 复制代码 
[root@VM-0-2-centos gitcode]# git branch -D dev
Deleted branch dev (was 571e576).

[root@VM-0-2-centos gitcode]# git branch
* master

⚠️ 警告 ：-D 是不可逆操作！删除后该分支的提交可能变成"孤儿提交"，无法通过普通方式找回。使用前务必确认该分支确实不再需要。

10.4 删除参数对比

参数 作用 使用场景
-d 安全删除 分支已合并，无风险
-D 强制删除 分支未合并，但确定废弃

10.5 实际工作流总结

复制代码 
需求评审 → 创建 feature 分支 → 开发中
                              ↓
                    ┌────────┴────────┐
                    ↓                 ↓
               开发完成            需求取消
                    ↓                 ↓
               合并到 dev          git branch -D feature
                    ↓
               删除 feature

结语：

至此，我们已经完整掌握了 Git 分支管理的核心技能。

从最初的一个 git branch dev 创建分支，到理解 HEAD → 分支 → 提交 的指针机制；从简单的 Fast-forward 合并，到复杂的冲突解决与 --no-ff 模式选择；从个人分支的灵活开发，到 git stash 保护现场紧急修复 Bug；再到最后 git branch -D 的果断清理------你已经具备了在真实项目中规范使用分支的能力。

分支管理的核心理念回顾：

原则 说明
master 稳定 仅用于发布，不直接开发
dev 集成 日常开发的主战场，功能完成后合并
个人分支隔离 每个任务独立分支，互不干扰
合并留痕迹 优先使用 --no-ff，保留历史可追溯
冲突本地解 先在开发分支合并 master，降低主分支风险

但 Git 的协作世界远不止本地分支。在后续的系列文章中，我们将继续探索：

篇章 核心内容
（三）远程操作与团队协作 git clone、git push、git pull，连接 GitHub/GitLab 实现多人协作
（四）标签管理与版本发布 git tag 为发布版本打标记，规范的版本控制流程
（五）企业级开发模型 Git Flow、GitHub Flow、Trunk-based 等主流开发模式

最后，送给你几个分支管理的实践心得：

原则 说明
分支要短小 一个分支只做一个功能或修复，完成后尽快合并删除
命名要清晰 feature/login-page、bugfix/memory-leak，见名知意
合并要审查 团队开发中，合并前进行 Code Review，避免问题代码流入主分支
现场要保护 紧急任务来临时，善用 git stash，不要带着脏代码切换分支

💡 练习建议 ：找一个自己的项目，尝试创建 dev 分支开发新功能，模拟合并冲突并解决，体验完整的分支生命周期。

分支让代码的演化有了并行与交汇的可能，而良好的分支策略，则是团队协作的润滑剂。愿你在代码的平行宇宙中，既能大胆探索，也能优雅合并。

相关推荐
必须会一定会2 小时前
Agent Handoff v0.6.0 跨电脑同步：Git、EVENTS.jsonl、CONTEXT.md 使用方法
人工智能·git·ai编程
cui_hao_nan9 小时前
Git常用命令1
运维·git
xxwl5859 小时前
Git常用命令的学习
git·学习
攻城狮-申9 小时前
git本地分支对齐远程分支
前端·git
七夜zippoe11 小时前
DolphinDB 2.0 配置管理实战：配置中心与版本控制落地指南
版本控制·配置中心·配置管理·dolphindb
不怕犯错，就怕不做19 小时前
git prune 自动删除本地记录中那些远程已经不存在的分支引用
linux·服务器·git
ELI_He9991 天前
如何还原已经推送的提交
git
️学习的小王1 天前
Git项目提交忽略文件怎么做？以Python项目为例，详解.gitignore
git·python·elasticsearch
愚蠢得人1 天前
Git Worktree实用指南：同时开发两个分支，不再反复切换
git
热门推荐
01国内可直接用、免费额度/永久免费的大模型API清单（含 SiliconFlow、火山、阿里、智谱、百度、Kimi、DeepSeek、DMXAPI 等）02GitHub 镜像站点03蜘蛛磁力 搜索引擎大全，如何使用蜘蛛磁力查找磁力链接04历年考研数学一、数学二、数学三真题试卷及答案PDF052026 国产 AI 大模型横评：DeepSeek、通义千问、Kimi、文心一言、星火、豆包谁更能打？06ZCode 周末送额度活动开启：3 亿 Token 免费领取07微信历史版本含下载地址（ Windows PC | 安卓 | MAC ）及设置微信不更新08AI 编程 IDE 全景解析 2026：Agent 全面接管开发链路09Agnes AI 免费 API 接入指南：文本、生图、生视频，一套接口全免费10VSCode+CodeX扩展，无法启动