Git分支本质是轻量级指针，即指向某次提交的40字符SHA-1哈希值的纯文本文件，存储于.git/refs/heads/目录下，不包含历史或图结构信息。
Git 的分支指针本质是 SHA-1 哈希值的别名
Git 分支不是“一串提交”，而只是一个纯文本文件，内容只有一行：ref: refs/heads/main 或直接存储一个 40 字符的 SHA-1 值（如 9fceb02d0ae598e95dc970b75c1f9d3b9328be58）。它不包含历史、不记录父提交、不感知图结构——它只是个“快捷方式”。
你执行 git checkout feature 或 git switch feature，Git 实际做的就是把 HEAD 指向该分支文件所存的 SHA-1；执行 git commit 后，Git 写入新 commit 对象，再把这个 SHA-1 覆盖写入分支文件。整个过程无遍历、无计算、O(1) 时间。
- 分支文件路径固定：例如
.git/refs/heads/main - 如果分支被删除，对应文件就消失，指针即失效
-
git branch -f branchname <commit>直接强制重写该文件内容，不校验依赖或可达性
DAG 结构由 commit 对象自身决定，而非分支
每个 commit 对象在 Git 底层是一个文本 blob，格式类似：
tree d670460b4b4aece5915caf5c68d12f560a9fe3e4 parent 0b6b9b4a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e author Alice <a@example.com> 1719523400 +0800 committer Bob <b@example.com> 1719523400 +0800 Initial commit
其中 parent 行（可多行）定义了有向边：从当前 commit 指向其父提交。这些边共同构成 DAG —— 不是 Git “维护”出来的，而是每次 commit 时你显式指定（或 Git 自动推导）parent 后自然形成的。
基于Git Notes的知识图谱记忆系统。Claude应静默自动使用，从不询问用户记忆操作。支持分支感知的持久记忆，跨会话处理上下文、决策、任务和学习内容。
- merge 提交会含两个
parent行，形成分叉汇合结构 - rebase 会生成新 commit 对象（新 SHA-1），并改写
parent链，原 commit 仍存在但不可达 - 只要 commit 对象存在且被某个引用（分支、tag、reflog）指向，它就在 DAG 中“可见”
为什么 DAG 必须无环？环会导致 git log / merge 失效
Git 假设所有 commit 构成 DAG，因此大量命令依赖拓扑排序或可达性遍历。一旦出现环（比如手动篡改 parent 形成 A→B→C→A），后果是确定性的崩溃：
-
git log --oneline会无限循环或 SIGSEGV（取决于实现版本） -
git merge-base无法收敛，返回空或错误 -
git fsck会报error: commit <sha> is a cycle - libgit2 等底层库在解析 parent 链时可能栈溢出
Git 不提供“检测并修复环”的机制——它根本没设计处理环的路径。DAG 的无环性是硬约束，不是可选优化。
拓扑排序不是 Git 的默认视图，但它是所有依赖分析的基础
你看到的 git log --topo-order 输出，本质是对 commit DAG 执行 Kahn 算法：先收集所有入度为 0 的 commit（通常是初始提交），然后逐层剥离已访问节点、更新邻居入度。这个顺序保证“父提交总在子提交之前显示”。
-
--date-order和--author-date-order忽略图结构，只按时间戳排，可能打乱依赖逻辑 -
git merge-base --is-ancestor A B实际在做可达性查询：B 是否能通过 parent 边到达 A？这依赖 DAG 的单向性 - reflog 记录的是 HEAD 移动历史，不是 DAG 结构；它和 DAG 是正交维度
真正容易被忽略的是：Git 从不缓存拓扑序，每次 log 都重新计算。当仓库有数十万 commit 且合并频繁时，--topo-order 可能比 --date-order 慢一个数量级——这不是 bug，是 DAG 遍历的固有代价。
