分支Branch

你可能会说

我想试试另一种做法，但又怕把现在这个能跑的版本搞坏。

从当前版本另开一条修改路线，让新功能先不混进主版本例如从当前稳定版本另开一条路线，只在这里修改和测试导航，确认后再合回主版本。它和主版本共享已有历史，同时把新的尝试暂时分开；切换前要先收好还没保存的改动。

先知道

提交 Commit

主版本保持稳定

从这里分开

新功能单独修改

git switch -c feature/new-nav

分支像一条独立的版本线。你可以在“新功能”这条线上修改和测试，主版本仍停在原来的稳定状态。

你可以这样告诉 AI Agent

请先收好当前改动并同步最新 main，再创建一个名称说明用途的导航实验分支。只在该分支修改和验证导航，不要直接改 main。完成后告诉我分支名、与 main 的差异和验证结果，先不要合并。

什么时候用

开发新功能或尝试较大的修改时，先从稳定版本创建分支
main
用 feature/new-nav 等能说明用途的名称
feature/new-navfeature/dark-mode
切换前先确认当前改动已经 Commit 或暂时收好
$ git switch mainSwitched to branch 'main'工作目录更新为 main 分支对应的文件版本
完成并测试后及时合回主版本，不让两边相差太久
main
feature

什么时候不用

直接在主版本上做不确定的大改动
main
使用 test1、aaa 等无法说明用途的分支名称
⑂ test1
⑂ aaa
⑂ 新建分支2名称未说明用途，后续难以区分分支
带着未保存的改动随意切换，导致内容出现在错误分支
$ git switch mainerror: Your local changes would beoverwritten by checkout.未提交改动可能阻止切换，或在切换后仍保留在工作目录
功能完成很久仍不合回，增加之后的合并难度
main

组成结构 · Anatomy

main

feature/new-nav

HEAD → 你现在在 feature/new-nav

常见的默认分支，通常保留已验证的改动；是否允许直接提交要看团队规则

新分支从某个 commit 创建，起点对应当时的快照

可按 feature/功能名命名，用于独立开发和测试

HEAD 指向当前检出的分支或提交，git switch 会更新其指向

常见变体 · Variants

创建分支switch -c

git switch -c feature/new-nav

从当前提交创建并切换到新分支

切回主分支switch

git switch main

切换工作目录到 main 的文件版本

列出分支branch

git branch

查看本地分支列表

删除分支branch -d

git branch -d feature/new-nav

确认分支已合并或不再需要后

典型使用场景

终端开新分支

zsh — my-first-page

$ git switch -c feature/new-nav Switched to a new branch 'feature/new-nav' 从当前提交创建并切换到新分支

GitHub 分支下拉切换

my-first-pagePublic

⑂ main ▾

切换分支

✓ main 默认

　feature/new-nav

查看所有分支（2）

VS Code 左下角分支名

        <nav class="top-nav">

          <a>首页</a>

        </nav>

⑂ feature/new-nav⊘ 0　⚠ 0Ln 3, Col 1

开始修改前确认左下角显示的当前分支

GitHub 分支列表页

你的分支

⑂ main默认2 小时前更新

⑂ feature/new-nav5 分钟前更新New pull request

main 现在稳定，你要尝试一套可能推翻的导航方案。怎样开始更安全？

A. 为这次导航实验创建一个全新的 Git 仓库B. 留在 main 直接修改，完成后再决定要不要保留C. 先收好当前改动，再从最新 main 创建用途明确的分支

ANS 原创方法

在真实工作流里用好这个术语

开源学习与复现

从探索广场点进 GitHub 仓库后，怎么学、怎么改、怎么留痕

先跑通原项目，再在独立分支上做小步改动；用 Diff、Commit 和测试记录你真正理解并修改了什么。