第七章. Git 分支管理教程：创建、切换与合并分支全流程

本章学习路径

1. 物理结构：通过直接向 .git/refs 目录写入哈希值，验证分支指针的存储开销与 O(1) 创建复杂度。
2. 指针流转：解析 HEAD 引用在分支切换（Switch）与游离状态（Detached HEAD）下的指向逻辑。
3. 合并算法：从图论视角透视 Fast-forward（快进）与 Recursive（递归）策略对历史线性的不同影响。
4. 冲突原理：构建三路合并（Three-way Merge）模型，理解 Base、Current、Incoming 三方在冲突消解中的角色。
5. 工程规范：建立标准化的分支命名体系与生命周期管理策略，避免仓库元数据膨胀。

7.1. 引用（Refs）的存储机制与指针操作

在许多传统版本控制系统（如 SVN）中，创建一个分支意味着要将整个项目目录在服务器端进行一次完整的物理拷贝。随着项目体积的增大，分支创建的时间成本和存储成本呈线性增长。

然而，在 Git 中，无论项目体积是 10MB 还是 100GB，创建一个新分支的时间复杂度永远是 O(1)，通常只需要几毫秒。这得益于 Git 独特的 引用（References，简称 Refs） 存储机制。

7.1.1. 实验：分支的物理本质验证

为了揭开分支的物理面纱，我们将绕过 Git 的高层命令，直接操作 .git 目录下的文件来“手动”创建一个分支。

【实战演练】环境准备

首先，确保我们处于一个干净的练习仓库中，并至少有一次提交。

1
2
3
4

# 初始化环境
echo "init" > file.txt
git add .
git commit -m "root commit"

步骤 1：获取当前提交的哈希值

我们需要知道当前 HEAD 指向的具体提交对象（Commit Object）的 SHA-1 哈希。

1
2

# 底层命令，用于我去某个节点的 hash 值
git rev-parse HEAD

预期输出（示例）：

1

5d670e739a0f826f30030cc6b20418cdb8e90a4a

请复制这串哈希值。

步骤 2：物理创建分支

我们不使用 git branch 命令。我们直接利用文件系统操作，在 Git 的引用目录下创建一个新文件。

1
2
3

# 将刚才复制的哈希值写入到一个新文件 'manual-branch' 中
# 注意：Windows CMD 用户请使用 echo a1b2... > .git\refs\heads\manual-branch
echo "5d670e739a0f826f30030cc6b20418cdb8e90a4a" > .git/refs/heads/manual-branch

步骤 3：验证分支存在性

此时，Git 应该已经识别到了这个新分支。

1

git branch

预期输出：

1
2

* master
  manual-branch

步骤 4：验证物理开销

查看该文件的大小：

1

ls -l .git/refs/heads/manual-branch

结果分析：文件大小精确为 41 字节（40 个字符的哈希值 + 1 个换行符）。

结论：
Git 的分支在物理层面上仅仅是一个 指向特定 Commit 对象的文本文件。创建分支的操作，本质上就是写入这 41 个字节。这就是 Git 分支操作极其高效的物理原因。

7.1.2. HEAD 引用的双层指向逻辑

HEAD 是 Git 中最重要的指针，它决定了用户的“当前工作位置”。理解 HEAD 的指向机制是掌握分支切换的关键。通常情况下，HEAD 是一个 符号引用（Symbolic Reference）。

【实战演练】解剖 HEAD

步骤 1：查看 HEAD 内容

1

cat .git/HEAD

预期输出：

1

ref: refs/heads/master

解析：这表示 HEAD 并没有直接指向某个哈希值，而是指向了 refs/heads/master 这个引用。

• 逻辑链条：HEAD -> refs/heads/master -> Commit SHA-1 -> Tree Object -> Files
• 动态特性：当你执行 git commit 时，Git 会更新 refs/heads/master 指向新的提交，而 .git/HEAD 文件本身的内容保持不变。

步骤 2：切换分支后的变化

切换到我们刚才手动创建的分支：

1
2

git switch manual-branch
cat .git/HEAD

预期输出：

1

ref: refs/heads/manual-branch

7.1.3. checkout：Git 的瑞士军刀命令

git checkout 可能是 Git 中最令人困惑的命令之一，因为它承担了太多职责。在 Git 2.23 版本后，官方将其拆分为 git switch 和 git restore，但理解 checkout 的原理对掌握 Git 仍然至关重要，毕竟在大多数教程中还是会直接的使用到 checkout 指令

【实战演练】checkout 的三种核心用法

用法一：切换分支

1
2
3
4
5
6
7
8
9
10

# 传统方式切换分支
git checkout manual-branch

# 背后发生了什么？
# 1. 更新 .git/HEAD 文件
cat .git/HEAD
# ref: refs/heads/manual-branch

# 2. 更新工作区文件到目标分支的状态
# 3. 更新暂存区（Index）到目标分支的状态

用法二：创建并切换分支

1
2
3
4
5
6

# 创建新分支并立即切换
git checkout -b feature/new-feature

# 等价于以下两条命令
git branch feature/new-feature
git checkout feature/new-feature

用法三：恢复文件（这是最容易混淆的用法）

1
2
3
4
5
6
7
8
9
10
11

# 场景：修改了文件但想撤销
echo "unwanted change" >> file.txt

# 从暂存区恢复文件（如果暂存区有的话）
git checkout -- file.txt

# 从特定提交恢复文件
git checkout HEAD~1 -- file.txt

# 从其他分支获取文件
git checkout other-branch -- specific-file.txt

7.1.4. checkout 的内部机制解析

让我们通过实验深入理解 checkout 的工作原理：

【实验一】文件级 checkout vs 分支级 checkout

1
2
3
4
5
6
7
8

# 准备实验环境
git switch master
echo "master version" > test.txt && git add test.txt && git commit -m "master: add test.txt"

git switch -c feature && echo "feature version" > test.txt && git commit -am "feature: modify test.txt"

# 回到 master
git switch master

现在我们有两个分支，test.txt 内容不同：

• master 分支：master version
• feature 分支：feature version

1
2
3
4
5
6
7
8
9
10

# 实验 1：分支级 checkout
git checkout feature
cat test.txt  # 输出：feature version
git status    # 工作区干净

# 实验 2：文件级 checkout
git checkout master
git checkout feature -- test.txt
cat test.txt  # 输出：feature version
git status    # 显示 test.txt 已修改！

关键区别：

• 分支级 checkout：更新 HEAD、工作区、暂存区
• 文件级 checkout：只更新工作区（和可能的暂存区），不移动 HEAD

7.1.5. checkout 的危险性与安全机制

【实验二】checkout 的数据保护机制

1
2
3
4
5
6
7

# 制造一个有未提交修改的场景
echo "important work" >> important.txt
git add important.txt

# 尝试切换分支
git checkout feature
# 错误：Your local changes would be overwritten by checkout

Git 的保护机制：

1. 检测冲突：如果切换会导致未提交的修改丢失，Git 会拒绝操作
2. 提供选项：

   1 2 3 4 5 6 7

   # 选项 1：先提交或储藏（我们后面会详细讲解） git stash git checkout feature git stash pop # 选项 2：强制切换（危险！） git checkout -f feature # 会丢失所有未提交的修改

7.1.6. checkout 的高级技巧

技巧 1：部分文件检出

1
2
3
4
5

# 只从另一个分支获取特定目录
git checkout feature -- src/components/

# 使用通配符
git checkout feature -- "*.config"

技巧 2：交互式文件恢复

1
2
3

# 交互式选择要恢复的内容块
git checkout -p -- file.txt
# Git 会逐块询问是否恢复

技巧 3：基于时间的 checkout

1
2
3
4
5

# 检出一周前的代码状态
git checkout 'master@{1 week ago}'

# 检出特定时间点
git checkout 'master@{2024-01-15 10:00:00}'

7.1.7. 从 checkout 到 switch/restore

Git 2.23 版本引入了两个新命令来替代 checkout 的不同功能：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

# 旧方式 vs 新方式对比

# 1. 切换分支
git checkout feature          # 旧
git switch feature           # 新（更清晰）

# 2. 创建并切换分支  
git checkout -b new-feature  # 旧
git switch -c new-feature    # 新

# 3. 恢复文件
git checkout -- file.txt     # 旧
git restore file.txt         # 新（语义更明确）

# 4. 从其他分支获取文件
git checkout feature -- file.txt    # 旧
git restore --source feature file.txt  # 新

为什么要拆分？

• 语义清晰：switch 专门用于分支切换，restore 专门用于文件恢复
• 减少误操作：避免因参数错误导致的意外行为
• 更好的提示：新命令提供更友好的错误信息和帮助

7.1.8. checkout 最佳实践

2. 谨慎使用文件级 checkout：

   1 2 3 4

   # 在执行前先查看会发生什么 git diff HEAD -- file.txt # 确认后再执行 git checkout HEAD -- file.txt

3. 建立安全习惯：

   1 2 3 4

   # 切换分支前检查状态 git status # 有修改时先储藏 git stash push -m "WIP: before switching to feature"

7.1.9 本节小结

• checkout 的本质：一个多功能命令，可以移动 HEAD（分支切换）或更新工作区文件（文件恢复）
• 核心区别：带路径参数时不移动 HEAD，不带路径参数时移动 HEAD
• 安全机制：Git 会阻止可能导致数据丢失的操作
• 演进方向：使用 switch/restore 获得更清晰的语义和更好的用户体验
• 实用技巧：掌握部分检出、交互式恢复等高级用法可以大幅提升效率

理解了 checkout 的全貌后，我们才能真正理解什么是 “游离头指针” 状态，以及为什么它既有用又危险。

7.2. 合并策略与提交历史的拓扑形态

“合并（Merge）” 是将两个分叉的历史轨迹重新汇聚的过程。Git 根据两个分支的拓扑结构不同，会自动选择 Fast-forward（快进） 或 Recursive（递归） 策略。这两种策略生成的历史图谱完全不同。

7.2.1. 快进合并

算法前提：当目标分支（Target Branch，如 master）的顶端提交，是源分支（Source Branch，如 feature）的 直接祖先 时。即：从 master 到 feature 是一条从未分叉的直线路径。

操作本质：
Git 不需要生成新的提交。它只需要将 master 指针顺着历史线 “向前滑动” 到 feature 的位置即可。

【实战演练】验证快进合并

准备工作：清理实验环境

1
2
3
4

# 确保当前的分支是 master 或 main
git switch master
# 重置到第一次提交的状态
git reset --hard origin/master

步骤 1：构建线性历史

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

# 1. 记录 master 当前位置
git log --oneline -n 1
# 输出：6c75c44 (HEAD -> master, origin/master) feat: init project with readme

# 2. 创建并切换到新分支（基于当前 master）
git switch -c feature/login

# 3. 模拟功能开发：产生两个提交
echo "用户登录逻辑" > login.js
git add login.js && git commit -m "feat: add login module"

echo "密码加密功能" > crypto.js
git add crypto.js && git commit -m "feat: add password encryption"

# 4. 查看当前分支状态
git log --oneline -n 3

此时的拓扑结构：

1
2

master 指向 --> 6c75c44 --> b71d2b2 --> 1958529 <-- feature/login 指向
               (初始节点）  （登录模块）  （加密功能）

步骤 2：执行快进合并

1
2
3
4
5

# 1. 切回 master（注意：master 仍指向 6c75c44）
git switch master

# 2. 合并 feature 分支
git merge feature/login

关键输出：

1
2
3
4
5
6
7
8

$ git merge feature/login
Updating 6c75c44..1958529
Fast-forward
 crypto.js | 1 +
 login.js  | 1 +
 2 files changed, 2 insertions(+)
 create mode 100644 crypto.js
 create mode 100644 login.js

步骤 3：验证结果

1
2
3
4
5
6
7
8
9
10
11

# 查看提交历史
$ git log --oneline -n 4
1958529 (HEAD -> master, feature/login) feat: add password encryption
b71d2b2 feat: add login module
6c75c44 (origin/master) feat: init project with readme


# 查看分支指向
$ git branch -v
  feature/login 1958529 feat: add password encryption
* master        1958529 [ahead 2] feat: add password encryption

结果分析：

• master 和 feature/login 现在指向 同一个提交（1958529）
• 历史保持 完全线性，没有额外的 merge commit
• 提交信息保持原样，看不出曾经有过分支

7.2.2. 递归策略

触发场景：当两个分支的历史出现了 分叉。即：master 分支在 feature 分支开发期间，自己也产生了新的提交。

【实战演练】验证递归合并

步骤 1：构建分叉历史

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

# 1. 确保在 master 分支
git switch master

# 2. 在 master 上创建一个新提交（模拟其他人的工作）
echo "# 项目文档更新 " >> README.md
git add README.md && git commit -m "docs: update README"

# 3. 基于 master 的上一个提交创建新分支（制造分叉）
git switch -c feature/payment HEAD~1

# 4. 在 feature/payment 分支上开发
echo "支付接口" > payment.js
git add payment.js && git commit -m "feat: add payment API"

echo "退款功能" > refund.js
git add refund.js && git commit -m "feat: add refund feature"

# 5. 查看分叉状态
git log --graph --oneline --all -n 5

此时的拓扑结构：

1
2
3
4
5

         master 指向 --> [docs: update README]
        /
[初始提交]
        \
         feature/payment 指向 --> [add payment API] --> [add refund feature]

步骤 2：执行递归合并

1
2
3
4
5

# 1. 切回 master
git switch master

# 2. 合并 feature/payment
git merge feature/payment

Git 会弹出编辑器，显示默认的合并信息：

1

Merge branch 'feature/payment'

保存并退出

步骤 3：深入理解合并结果

1
2

# 1. 查看图形化历史
git log --graph --oneline -n 6

输出解析：

1
2
3
4
5
6
7
8

*   a64df7e (HEAD -> master) Merge branch 'feature/payment'
|\
| * d467b1a (feature/payment) feat: add refund feature
| * f2051f6 feat: add payment API
* | 5883b87 docs: update README
|/
* 1958529 (feature/login) feat: add password encryption
* b71d2b2 feat: add login module

关键发现：

• 生成了一个新的 Merge Commit（a64df7e）
• 这个提交有 两个父节点：d467b1a 和 5883b87
• 历史形成了 菱形结构，清晰展示了并行开发的过程

7.2.3. 工程化规范：–no-ff 的应用

在理解了快进合并和递归合并之后，你可能会想：既然快进合并能保持历史简洁，为什么还要刻意避免它呢？这就涉及到大型项目中的一个核心问题：如何让提交历史具有更好的可读性和可管理性。

现实场景的痛点

假设你的团队正在开发一个电商系统。张三负责开发用户登录功能，在 feature/login 分支上工作了一周，产生了 15 个提交：

• 初始化登录页面
• 添加表单验证
• 修复验证 bug
• 接入后端 API
• 处理异常情况
• 优化性能
• …

如果使用快进合并，这 15 个提交会直接 “平铺” 到 master 分支上。三个月后，当你需要回顾或回滚 “登录功能” 时，你会发现一个严重问题：你无法快速识别哪些提交属于这个功能。它们已经和其他功能的提交混在一起，形成了一条冗长的直线。

–no-ff 的设计哲学

--no-ff（no fast-forward）参数强制 Git 创建一个合并提交，即使当前情况满足快进条件。这个看似 “多余” 的提交，实际上扮演着 功能边界标记 的角色。

它带来的价值：

1. 逻辑分组：相关的提交被 “包裹” 在一个可识别的结构中
2. 便于回滚：可以通过 revert 一个 merge commit 来撤销整个功能
3. 清晰的协作历史：一眼就能看出哪些提交是一起合并进来的
4. 代码审查友好：审查者可以将一组相关改动作为整体来理解

可视化对比

使用快进合并后的历史：

1

[主线功能A] -> [登录-初始化] -> [登录-验证] -> [主线功能B] -> [登录-API] -> [登录-优化] -> ...

所有提交混在一条线上，难以区分功能边界。

使用 --no-ff 后的历史：

1
2
3

[主线功能A] -> [主线功能B] -> [Merge: 登录功能] -> [主线功能C]
                \                                /
                 [登录系列：初始化->验证->API->优化]

功能分支形成一个清晰的 “气泡”，一目了然。

【实战演练】体验 --no-ff 的价值

让我们通过一个完整的场景来体验这种差异。

场景设置：模拟一个真实的功能开发流程

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

# 1. 准备干净的环境
git switch master
git switch -c feature/shopping-cart

# 2. 模拟功能开发过程（多个相关提交）
echo "购物车基础结构" > cart.js
git add cart.js && git commit -m "feat: initialize shopping cart"

echo "添加商品功能" >> cart.js
git add cart.js && git commit -m "feat: add item to cart"

echo "计算总价" >> cart.js
git add cart.js && git commit -m "feat: calculate total price"

# 3. 此时查看分支状态
git log --oneline -n 3

使用 --no-ff 合并

1
2
3
4
5

# 切回主分支
git switch master

# 使用 --no-ff 进行合并
git merge feature/shopping-cart --no-ff -m "feat: 完成购物车功能模块 (#PR-123)"

查看并理解结果

1
2
3
4
5

# 查看合并后的历史图形
git log --graph --oneline -n 6

# 查看合并提交的详细信息
git show HEAD

你会看到：

1
2
3
4
5
6
7

*   8eb39b3 (HEAD -> master) feat: 完成购物车功能模块 (#PR-123)
|\
| * 71bb54f (feature/shopping-cart) feat: calculate total price
| * 95d091f feat: add item to cart
| * bd278f8 feat: initialize shopping cart
|/
* 6c75c44 (origin/master) feat: init project with readme

1. 生成了一个明确的合并提交：“feat: 完成购物车功能模块”
2. 这个提交有两个父节点，形成了一个可识别的分支结构
3. 购物车的所有相关提交被 “包含” 在这个结构中

工程实践中的应用

在成熟的开发流程（如 Git Flow、GitHub Flow）中，–no-ff 通常用于：

1. 功能分支合并：

   1	git merge --no-ff feature/user-authentication

2. 发布准备：

   1	git merge --no-ff release/v2.0.0

3. 紧急修复：

   1	git merge --no-ff hotfix/security-patch

回滚的便利性

当使用了 --no-ff 后，回滚整个功能变得极其简单：

1
2

# 假设需要回滚购物车功能
git revert -m 1 HEAD  # 回滚最近的合并提交

相比之下，如果使用了快进合并，你需要：

1. 找出属于购物车功能的所有提交（可能散落在历史中）
2. 逐个 revert 这些提交
3. 处理可能的冲突

这种差异在功能包含几十个提交时尤为明显。

最佳实践建议

• 主干分支合并：始终使用 --no-ff，保持清晰的功能边界

• 个人临时分支：可以使用快进合并，减少历史噪音

• 配置默认行为：

  1 2	# 为特定分支设置默认的合并策略 git config branch.master.mergeoptions "--no-ff"

通过合理使用 --no-ff，你的项目历史将从一条冗长的直线，转变为一个结构清晰、易于理解的功能演进图谱。这种看似 “多一个提交” 的小改变，在项目的长期维护中会带来巨大的价值。

7.2.4. 本节小结

合并策略对比表

实践建议：

1. 个人开发：频繁的小修改可以使用快进合并，保持历史简洁。

2. 团队协作：

   • 功能分支（feature/*）合并到主线时，使用 --no-ff
   • 形成的 “气泡” 让每个功能的边界一目了然

3. 回滚友好性：

   • 快进合并：回滚困难，需要逐个 revert 提交
   • 非快进合并：可以直接 revert 整个 merge commit，一次回滚整个功能

7.3. 冲突检测算法与三路合并

当两个分支修改了同一个文件的同一部分时，Git 会报告冲突。理解冲突的产生机制和解决方法，是协作开发的必备技能。

7.3.1. 为什么是 “三路”？

很多人误以为合并只涉及两个分支，实际上 Git 使用的是 三路合并算法。这个 “第三路” 是什么？让我们通过一个生活化的例子来理解。

场景类比：假设你和同事基于同一份项目提案（v1.0）分别进行修改：

• 你把预算从 10 万改成了 15 万
• 同事把预算从 10 万改成了 20 万

现在需要合并，Git 怎么知道原始预算是 10 万？这就需要 共同祖先 作为参照。

三路合并的参与者：

1. Base（共同祖先）：分支分叉前的状态（原始的 10 万）
2. Ours（当前分支）：你的修改（15 万）
3. Theirs（目标分支）：同事的修改（20 万）

有了 Base，Git 就能判断：

• 如果只有一方修改了某行，自动采用修改
• 如果双方都修改了同一行，产生冲突，需要人工决策

7.3.2. 实验：制造并解决真实冲突

让我们通过一个接近实际开发的场景来体验冲突的产生和解决。

场景：两个开发者同时修改配置文件

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

# 1. 创建初始配置文件
cat > config.json << EOF
{
  "appName": "MyApp",
  "version": "1.0.0",
  "apiUrl": "https://api.example.com",
  "timeout": 3000
}
EOF

git add config.json
git commit -m "feat: initial config"

# 2. 开发者 A 在 feature-a 分支修改超时时间和 API 地址
git switch -c feature-a
cat > config.json << EOF
{
  "appName": "MyApp",
  "version": "1.0.0",
  "apiUrl": "https://api-v2.example.com",
  "timeout": 5000
}
EOF
git add config.json
git commit -m "feat: update API endpoint and increase timeout"

# 3. 开发者 B 在 feature-b 分支修改版本号和超时时间
git switch master
git switch -c feature-b
cat > config.json << EOF
{
  "appName": "MyApp",
  "version": "1.1.0",
  "apiUrl": "https://api.example.com",
  "timeout": 6000
}
EOF
git add config.json
git commit -m "feat: bump version and adjust timeout"

# 4. 合并 feature-a 到 master（成功）
git switch master
git merge feature-a --no-ff -m "Merge feature-a: API updates"

# 5. 尝试合并 feature-b（产生冲突）
git merge feature-b --no-ff

查看冲突状态

1
2
3
4
5

# 查看哪些文件有冲突
git status

# 查看冲突的详细信息
git diff --name-only --diff-filter=U

7.3.3. 解决冲突的完整流程

步骤 1：理解冲突标记

打开 config.json，你会看到：

1
2
3
4
5
6
7
8
9
10
11
12

{
  "appName": "MyApp",
<<<<<<< HEAD
  "version": "1.0.0",
  "apiUrl": "https://api-v2.example.com",
  "timeout": 5000
=======
  "version": "1.1.0",
  "apiUrl": "https://api.example.com",
  "timeout": 6000
>>>>>>> feature-b
}

冲突标记解读：

• <<<<<<< HEAD：当前分支（已包含 feature-a）的内容开始
• =======：分隔线
• >>>>>>> feature-b：要合并的分支内容结束

步骤 2：分析冲突原因

使用 diff3 风格查看更多信息：

1
2
3
4
5
6

# 配置 diff3 风格（显示共同祖先）
git config merge.conflictStyle diff3

# 重新查看冲突
git checkout --conflict=diff3 config.json
cat config.json

现在你能看到三方的内容：

1
2
3
4
5
6
7
8
9
10
11
12
13

<<<<<<< HEAD
  "version": "1.0.0",
  "apiUrl": "https://api-v2.example.com",
  "timeout": 5000
||||||| merged common ancestors
  "version": "1.0.0",
  "apiUrl": "https://api.example.com",
  "timeout": 3000
=======
  "version": "1.1.0",
  "apiUrl": "https://api.example.com",
  "timeout": 6000
>>>>>>> feature-b

步骤 3：决策并解决

根据业务需求，决定最终版本。假设我们需要：

• 使用新版本号（1.1.0）
• 保留新的 API 地址（api-v2）
• 取较大的超时值（6000）

手动编辑文件：

1
2
3
4
5
6
7
8
9
10

# 方法 1：手动编辑
vim config.json
# 删除所有冲突标记，保留需要的内容

# 方法 2：使用 git checkout 选择某一方
# git checkout --ours config.json    # 完全使用当前分支版本
# git checkout --theirs config.json  # 完全使用传入分支版本

# 方法 3：使用合并工具
git mergetool  # 会启动配置的合并工具

最终文件内容：

1
2
3
4
5
6

{
  "appName": "MyApp",
  "version": "1.1.0",
  "apiUrl": "https://api-v2.example.com",
  "timeout": 6000
}

步骤 4：标记解决并提交

1
2
3
4
5
6
7
8
9
10

# 标记文件已解决
git add config.json

# 查看解决状态
git status

# 继续合并
git merge --continue
# 或者直接提交
# git commit

7.3.4. 进阶：逻辑冲突（Semantic Conflict）

这是最隐蔽、最危险的冲突类型。Git 认为合并成功，但代码跑不起来。

场景模拟：

1. Base：定义函数 processData(int a)。
2. Ours：重构代码，将函数改为 processData(int a, int b)（增加参数）。
3. Theirs：新增代码，调用了旧的 processData(10)。

结果：

• 物理上，Ours 改的是定义行，Theirs 改的是调用行。两行不重叠。
• Git 三路合并判定：无物理冲突，自动合并成功。
• 后果：编译失败。因为 Theirs 的新代码在调用一个不存在的函数签名。

防御机制：这就是为什么 CI（持续集成） 如此重要。仅仅 Git 合并成功是不够的，必须在合并后立即运行自动化测试，以捕获这种“逻辑冲突”。

7.4. 分支管理规范与元数据清理

随着项目迭代，仓库中会积累成百上千个分支。如果不加管理，.git/refs 目录会变得臃肿，不仅影响 git branch 的列出速度，还会造成严重的认知负担。

7.4.1. 结构化命名规范

Git 允许在分支名中使用斜杠 /。这不仅是命名习惯，更对应着 物理目录结构。

命名 Schema：
type/scope/description

示例：

• feat/user/login-api
• fix/order/invoice-calculation
• release/v1.2.0

【实战验证】物理目录结构

1
2

git branch feat/user/login-api
ls -F .git/refs/heads/

预期输出：你会发现 Git 自动创建了 feat 目录，里面有 user 目录。这种层级结构使得我们可以利用通配符进行批量操作（如 git branch -D feat/user/*）。

7.4.2. 引用清理与生命周期

分支一旦合并进主干，它的历史使命就结束了，应立即删除。

安全删除 (-d)：

1

git branch -d feature/login

Git 会进行 Merged Check（合并检查）。它会检查 feature/login 的所有提交是否都已经存在于当前分支。

• 如果已合并：删除成功。
• 如果包含未合并的提交：Git 报错 error: The branch ... is not fully merged，防止数据丢失。

强制删除 (-D)：

1

git branch -D feature/abandoned-idea

等同于 --delete --force。告诉 Git：“我知道这里面有未合并的代码，我确定要丢弃它们。”

清理远程追踪分支：有时候，队友已经删除了远程的 feature 分支，但你的本地依然显示 origin/feature。

1
2
3

git fetch -p
# 或
git remote prune origin

-p (prune) 参数会修剪掉那些“远程已经不存在，但本地还保留着”的追踪引用，保持环境整洁。

7.5. 本章小结

本章我们深入到了 Git 分支管理的“机房内部”，通过文件系统验证了引用的轻量级特性，并解构了合并操作背后的算法逻辑。

核心知识体系回顾

1. 物理结构：
   • 分支是指向 Commit 的 41 字节文本文件。
   • HEAD 是指向分支引用的符号引用。
2. 合并拓扑：
   • Fast-forward 保持线性历史，但丢失上下文。
   • Recursive 生成 Merge Commit，保留分叉结构。
   • --no-ff 是企业级开发保留特性气泡的标准操作。
3. 冲突原理：
   • 三路合并依赖 Base（LCA）来判定变更方向。
   • 物理冲突通过标记符解决，逻辑冲突依赖自动化测试防御。
4. 管理规范：
   • 使用目录级命名（feat/xxx）管理引用空间。
   • 定期 Prune 远程引用，防止仓库膨胀。

速查代码清单

1
2
3
4
5
6
7
8
9
10
11

# 1. 物理查看引用
cat .git/refs/heads/<branch>

# 2. 禁止快进合并
git merge --no-ff <branch>

# 3. 强制删除未合并分支
git branch -D <branch>

# 4. 清理无效远程引用
git fetch -p