小红帽的灰灰狼Git的分支与指针：深入理解Git的分支是如何工作的
1. 为什么多数人对Git分支的理解是错的
我见过太多开发者在Git上翻车，根源几乎都指向同一个问题：把Git分支理解成了类似SVN的"目录拷贝"。这种误解会带来一连串的怪现象——切换分支时提心吊胆，生怕工作区代码被覆盖；合并分支时满屏冲突无从下手；一不小心把分支删了就觉得天塌了。
要说清楚Git的分支到底怎么工作，绕不开一个核心概念：指针。Git的分支本质上不是一个装着文件的目录，而是一个轻量的、可移动的指针，它指向某个提交对象。每次你执行git commit，Git就会创建新的提交对象，并把当前分支指针移动到新提交上。理解了这一层，前面那些恐慌基本能消除一大半。
打个比方，把提交历史想象成一条项链，每次提交就是串上新的一颗珠子，分支就是套在珠子上的一个标签。你可以随时把这个标签从一颗珠子移到另一颗珠子上，珠子本身并没有被复制或破坏。这就是为什么Git创建分支、切换分支会快得离谱——它做的只是移动指针和更新工作区内容，而不是真的去复制一整个项目目录。
这篇文章适合所有被Git分支"逼疯"过的开发者，无论你是刚学Git的新手，还是已经日常使用但从未深究内部原理的老手。我会从提交对象、HEAD、分支指针这几个最底层的东西讲起，再串联到分支创建、切换、合并、删除这些日常操作，最后用几个实战中常见的"事故现场"演示指针模型是如何帮我们快速定位和修复问题的。写到最后你会发现，整个Git分支模型其实就是三个指针在协作，一旦看清这盘棋，很多操作都不需要死记硬背了。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 从提交对象说起：先搞清楚指针指向的是什么
2.1 一个提交里到底装了什么
在理解分支之前，得先搞清楚分支指针指向的那个"提交"到底是什么。Git仓库里的一切都是对象，提交对象（commit object）是其中最重要的一类。每次你执行git commit，Git会生成一个40位的哈希值来唯一标识这次提交，这个提交对象里包含四样东西：
- 快照信息：指向本次提交时暂存区内容对应的树对象（tree object），可以理解为整个项目的完整文件状态索引
- 父提交：指向上一次提交的哈希值，多个父提交意味着这次提交是一个合并提交（merge commit）
- 作者与提交者信息：姓名、邮箱、时间戳
- 提交信息：你写的
-m "xxx"内容
其中最关键的就是父提交这个字段。正是通过"每个提交都记录自己的父提交是谁"这条链路，所有提交才能串成一条完整的历史线。你可以通过git cat-file -p HEAD查看当前提交的完整内容，直接观察这个结构。
code复制$ git cat-file -p HEAD
tree 8a2f4a3e8a3e0b639f1d9f4c1f0e6b1c3d5f7a9b
parent 7d5c0f2e1a9b8c7d6e5f4a3b2c1d0e9f8a7b6c5
author Zhang San <zhangsan@example.com> 1691234567 +0800
committer Zhang San <zhangsan@example.com> 1691234567 +0800
feat: 添加用户登录模块
这条链就是Git的"时间线"。无论你分支切到哪、合并到哪、回退到哪，提交对象本身是只读的、不变的。Git里没有"修改历史"这个操作，任何历史变更本质上都是创建了新的提交，然后让指针指向新位置。
2.2 快照不是差异补丁
很多从SVN转过来的朋友会惯性认为，Git存储的提交是"基于上一个提交的差异补丁"，所以提交历史越长，仓库里存的差异就越多。真实情况是，Git每个提交都保存一份完整的项目快照——更准确地说，是通过树对象记录当时所有文件的完整路径和内容引用。相同内容的文件会被去重复用，但这和"只存差异"有本质区别。
这个设计带来的直接好处是：Git可以在任意两个提交之间瞬间计算差异，而不需要从头开始"重放"所有补丁。比如git log -p能快速展示任意历史提交的改动内容，git diff A B能直接比较两个任意提交，靠的都是快照机制。从经验看，理解"提交=快照+元信息"比理解"提交=补丁"要接近真相得多，后续学rebase、cherry-pick等操作也会顺畅很多。
2.3 用父提交链理解"历史是一张图，不是一条线"
提交对象通过parent字段首尾相连，但这张图并不总是单线直行的。当两个分支各自产生了新的提交后，历史就分叉了。分叉之后再合并，合并提交会有两个父提交，历史图就出现了"汇合点"。
平时排查问题，我固定会用这两个命令看历史图：
code复制$ git log --graph --oneline --all
$ git log --graph --oneline --decorate
第一个命令会画出所有分支的提交拓扑，第二个会在提交旁边标出分支指针位置。图上每一个*或o字符都对应一个提交对象，括号里的HEAD -> main、origin/dev等就是各个指针当前的位置。当你看到一条带分叉又合并的历史图，再看分支从哪分出、从哪汇合，很多"代码怎么丢的""这个改动是哪来的"的问题，答案自己就浮现出来了。