创建分支与隔离开发

分支不是文件夹拷贝，而是活动指针

在很多人的直觉中，开辟一个新分支就像是在电脑里把整个工程文件夹完整复制了一遍。如果真的这样实现，项目的体积很快就会膨胀几十倍，在不同文件夹之间同步代码也会变得非常繁琐。

在 Git 的底层实现中，分支↗ 本质上只是一个指向特定 Commit 的可移动 指针↗。创建新分支并不需要复制任何文件，它仅仅是在当前的提交节点上贴了一个新的活动标签，所有分支共同存放在同一个项目仓库中。

当我们在某个分支上持续产生新的提交时，该分支指针会自动向前移动，指向最新生成的快照。而其他分支的指针则保持在原来的位置，互不影响。创建分支非常轻量，切换分支时 Git 会更新工作区中的对应文件。如果从主干切出新功能分支后，主干又单独提交了修复，两条分支就会各自向前演进，形成不同的提交节点。

HEAD 是当前检出位置的坐标

既然仓库中可以同时存在多个分支指针，Git 又是如何知道我们当前正在哪一个分支上工作呢？答案是 HEAD 这一特殊 指针↗。

HEAD 是 Git 内部的一个特殊引用，相当于指示我们当前所在位置的坐标。通常情况下，HEAD 指向我们当前所在的本地分支名，例如 main 或 feature/cart。

当我们执行切换分支的操作时，Git 会做两件事：首先让 HEAD 改为指向目标分支的指针；接着，Git 会按目标版本更新需要变化的已跟踪文件与暂存区。初学者在切换分支后，常会发现编辑器里的代码文件突然变了，甚至某些刚写的文件不见了；这并不是代码被误删了，而是 Git 正在同一个文件夹里展示目标分支所保存的版本，切回原分支后便会完整复原。

切换分支前，建议先运行 git status 确认工作区是干净的。未提交的改动不一定会阻止切换，也不会自动归属于某个分支。 如果不会覆盖目标分支的内容，Git 可能会把这些半成品修改直接带到新分支上，造成改动混淆；如果会发生覆盖，Git 通常会报错并拒绝切换。因此在切换分支前，要么把已验证的代码提交，要么按第六章介绍的方法临时存放，避免带着未提交的改动随意切换。

你可以直接对 Agent 说：“基于当前的 main 分支，新建一个名为 feature/cart 的分支并切换过去，然后开始写购物车功能。”

Agent 底层执行的正是 git switch -c feature/cart（-c 代表创建并切换）；后续想切回主线，只要说“切回 main 分支”，对应的是 git switch main。你可以随时询问 Agent“当前所在的分支”，或者查看编辑器底部状态栏，确认当前所在的分支名。

怎样让 AI 在独立分支上尝试新功能

借助 AI 探索新功能与 Vibe Coding↗ 时，我们往往会产生很多试验性的想法，例如尝试一种全新的设计风格、重构底层数据结构，或者引入新的组件库。这些尝试不一定每次都能成功。

如果我们直接在 main 主分支上让 AI 大幅修改，一旦效果不理想，想要完全恢复就会变得很麻烦。规范的做法是：每次尝试新想法之前，都要求 AI 先从最新的基线拉出一个专用的独立分支。

在 feature/cart 上提交，不会自动移动 main 的分支指针；但同一工作区里的未提交文件仍可能跟着切换走。实验不满意时，先处理这些文件，再决定是否保留分支上的提交。删除分支只是删除引用，不是撤销工作区改动。 不确定是否还要代码时，先保留分支，按第六章明确恢复范围。