新功能、Bug修复和文档修改是否需要新分支，取决于任务边界、验收要求和仓库工作流。

新分支更适合对应一个需要独立开发、审查和集成的任务，而不是对应一轮对话、一个文件或一次提交。 对个人项目和AI辅助开发，我推荐的默认做法是：独立功能或修复在修改前开短期任务分支，同一任务的补测、文档和审核修复继续留在原分支。

这是一套轻量协作约定，不是Git强制要求。若仓库明确采用直接提交主线的流程，应遵守其权限与验证规则；如果推送会自动部署，还要单独确认部署授权。

本文依据2026年10月29日核对的Git与GitHub官方文档，并对几个常见操作做了隔离仓库验证。命令中的远端、分支和版本名均是示例；没有在真实项目中执行分支恢复、生产推送或版本发布。

新建分支与复用分支的适用场景

具有独立目标、可单独验收并决定是否合并的改动，通常适合使用独立任务分支。

Pro Git的分支工作流章节介绍了围绕单一特性或相关工作创建主题分支的做法。GitHub flow也采用轻量的分支、审查和合并流程。这两项资料支持任务分支的组织方式，不代表所有项目都必须建立相同的长期分支结构。

场景 推荐的默认处理 判断重点
新功能、独立Bug修复 修改前创建任务分支，即使只有一个提交 能否单独验收与集成
独立重构、性能优化、依赖升级、数据迁移 创建独立分支 是否需要独立评估兼容性与回退
风险不确定的实验 使用实验分支 未验证的方案不要混进稳定主线
当前任务未完成，又开始无关任务 新任务用新分支，必要时另建worktree 保留现场，避免夹带未完成工作
同一功能的补测、文档和审核修复 继续当前任务分支 是否仍服务同一个验收目标
只读代码、诊断、运行已有测试 不因只读操作创建分支 需要保存修复时再决定分支
独立文档修改 通常使用docs分支 仓库规则或明确授权允许时可直接提交主线
已发布版本紧急修复 从实际发布基线创建hotfix分支 不夹带主线上尚未发布的功能

改动行数不能单独决定是否创建分支。一条条件表达式也可能影响数据写入；多个文件的修改也可能只是同一功能的完整交付。分支边界应跟着任务和验收条件走。

新建或复用分支的任务边界：只读、补测文档、独立开发、并行任务和紧急修复
作者建议示意：以独立目标与验收边界判断，不按文件或提交数量机械划分。

分支创建时机与基线选择

独立任务的分支应在修改开始前创建。创建前确认当前分支、未提交修改和目标集成线，再选择基线，避免从无关的功能分支派生。

工作目标 通常考虑的起点 需要确认的条件
下一轮正常集成的新功能或修复 已同步的目标集成分支 是否存在未同步或未集成的本地提交
当前线上版本的紧急修复 实际发布标签或对应维护分支 标签是否确实对应运行中的版本
多条版本线分别维护 各自维护线 修复需要同步到哪些后续版本
明确依赖未合并任务B的任务C B的任务分支 记录依赖、审查范围和合并顺序

以下示例假设目标集成线为origin/main，fetch配置能正常更新该引用，且工作区已确认干净：

1
2
3
4
5
git status --short
git branch --show-current
git fetch origin
git log --oneline --left-right main...origin/main
git switch --no-track -c feat/report-export origin/main

git fetch用于获取远端对象并按配置更新引用，不自动将改动合入当前工作分支；详见git-fetch文档。main...origin/main只展示两者的提交差异，不处理差异。若本地main还有本次必须包含的提交，应明确它们的集成安排，不能默认从origin/main创建分支就已包含这些工作。

--no-track明确不把新任务分支的上游自动设成origin/main。之后需要推送时，再明确指定同名任务分支和相应权限。这一选项与新建/切换语义见git-switch文档。

如果任务针对实际发布的v1.4.2，则示意为：

1
git switch -c hotfix/session-expiry v1.4.2

版本名仅作示例，执行前必须确认真实基线。它不会自动把修复同步到其他维护线，也不会创建新版本或发布标签。

分支、提交、标签与worktree的区别

对象 用途 不应混为一谈的事情
分支 用一个引用组织持续演进的提交历史 不等于一个文件夹或一轮聊天
提交 记录一次代码快照及其历史关系 一个任务分支可以有多个提交
标签 标识一个特定历史点，常用于版本基线 不等于持续承载开发的分支
worktree 为同一仓库提供额外工作目录 不等于账号、端口、数据库或运行环境隔离

同一功能经过“实现→补测试→修审查问题→补文档”，通常仍在同一任务分支里。每次开新对话就切新分支，会把一个验收目标拆散；把不相关任务长期塞进同一分支，则会让审查和集成难以单独决定。

大型目标可以在设计允许的情况下拆成可独立验证、不会破坏既有行为的小增量，分批合并。主干开发资料强调短期分支与及时集成，详见Short-Lived Feature Branches；它是一种工作流观点，不能机械转化为所有团队统一的天数或分支数量指标。

未提交修改的分支处理

main上尚未提交的报表导出修改，经确认均属于同一任务时，可以从当前HEAD创建分支：

1
2
3
4
5
git status --short
git diff
git diff --cached
git switch -c feat/report-export
git status --short

从当前HEAD新建分支，不会自动清空工作区，也不会替你将不同任务拆开。 本文在隔离仓库中验证：这种场景下，已有的工作区修改、暂存内容和未跟踪文件均保留，main指向的提交没有改变。

这与切换到另一条已有历史不同。涉及会被覆盖的本地改动时，Git通常会拒绝切换；不要把拒绝提示直接理解为需要强制切换，也不要把它当成所有未跟踪数据的备份保证。确认文件归属和保存状态后，再选择提交、显式暂存方案或独立工作目录。

例如，一半是本次Bug修复，另一半是尚未完成的新功能，仅执行新建分支并不能把它们分离。需要按文件或代码块整理；无法可靠拆开时，先保留当前现场，用另一个worktree处理独立任务更清楚。

main已有提交的分支处理

处理已有提交前，应检查提交历史及共享状态，避免破坏性恢复。

从当前提交建立新引用并切换到该分支：

1
2
git branch feat/report-export
git switch feat/report-export

在示例中，执行前的main指向提交C；执行后，main和feat/report-export仍同时指向C。新建分支没有将C从main“搬走”。这可由git-branch文档中的创建语义解释，本文也做了隔离验证。

如果后续还要整理main，应继续确认：这些提交是否已推送、是否被他人基于其开发、仓库是否允许调整历史。已共享历史的修正，需要按协作规则安排新的修正提交或集成方案；不能为了让提交图看起来整齐就擅自重写。

以上操作仅为现有提交建立任务引用，不会恢复main。main的整理方式取决于实际提交关系和共享状态，不能直接套用强制重置或强制推送命令。

使用worktree并行处理任务

功能A的工作区仍有未提交修改，而独立修复B需要并行处理时，可以保留原目录，在额外工作目录中创建B的任务分支：

1
git worktree add --no-track -b fix/session-expiry ../project-session-fix origin/main

示例要求origin/main已经按目标基线核对，分支名未被占用，目标目录可用于新工作树。本文在隔离仓库中确认：原目录的未提交修改保持不变，新目录使用独立分支且工作区干净。

git-worktree文档说明了额外工作树及分支占用限制。通常不要将同一分支同时检出到多个工作树；不同任务各自使用分支与目录，减少互相干扰。

但这种隔离主要针对工作目录与索引。仓库对象和部分引用、配置仍共享；两个实例也可能连接同一个数据库、占用同一个端口，或写同一份账号数据。需要运行时隔离时，应另行配置数据目录、端口和输出，不能直接复制真实Cookie或大型浏览器目录到工作树里。

worktree只是组织并行工作的工具，不是增加未完成任务数量的理由。长期不集成的分支仍会逐渐偏离目标主线，额外目录也需要明确负责人、用途和清理条件。

同一仓库中的分支历史与独立worktree工作目录，以及运行数据仍需隔离的关系
原理示意：worktree隔离工作文件与索引，不自动隔离数据库、账号和端口。

分支审核、合并与清理

合并前后的检查与清理步骤如下：

  1. 重新获取目标分支的状态，检查相对于目标的实际差异；依赖分支要区分继承改动与本次新增改动。
  2. 完成相关审查、敏感信息检查和与改动相称的测试，补齐受影响的文档与变更日志。
  3. 如果目标分支已经变化，按项目规定同步，并判断是否需要补充集成验证。
  4. 按既有权限与仓库规则合并，核对实际集成提交、CI及必要验证结果。
  5. 确认没有未合并提交或未保存文件后，再清理任务分支和worktree。

同步和合并方式由项目规则决定。Git的合并文档说明了冲突等行为；创建了任务分支并不意味着合并时不会冲突，也不意味着可以随意rebase共享分支。

GitHub保护分支文档提供审查、状态检查等可配置要求。这些是托管平台的保护措施，不能只靠分支命名实现，也不能将CI通过当作业务行为已全部验证。

本地删除分支时，git branch -d会根据上游或当前HEAD检查合并关系，不能将它当成“已合入指定目标分支”的完整证明。使用squash等方式集成后，提交祖先关系也可能与原分支不同。删除被拒绝时先确认实际集成结果，不应立即改用强制删除；worktree清理也先确认没有待保存文件。

任务分支推送不等于主线合并，主线合并也不天然等于正式发版。 如果仓库工作流会因推送或合并直接部署生产环境，就必须先取得该部署范围的授权。版本号、标签、Release和软件分发分别按项目所有者确认的范围执行，不能以“只是推送”绕过发布决定。

分支策略的常见问题

长期开发分支与发布分支的适用条件

个人项目无需默认建立长期develop分支或为每次发版创建release分支。本文推荐主分支保持可验证、可交付，独立任务用短期分支；多版本并行维护、发布冻结或其他明确需求出现时，再决定是否建立release或维护分支。项目已采用其他流程时，先理解其交付方式和约束。

分支、提交与版本的关系

一个任务可以包含实现、测试、文档等多个相关提交；一次版本发布也可能汇总多个任务。分支名里的feat或fix不直接决定SemVer版本级别，兼容性影响需要另行评估。

AI协作中的任务与分支划分

AI协作按任务目标与工作目录划分分支。同一任务的顺序实现、审查和修复可以复用分支；真正并行、可能互相修改文件的独立任务，需要协调范围并使用合适的分支与工作树。工具角色不同，并不自动意味着任务边界不同。

需要独立开发、验收和集成的任务，应在修改前建立任务分支；同一任务的补充修改继续使用原分支。分支划分以变更边界为依据。

参考资料

以下资料于2026年10月29日查阅。Git手册用于核对命令语义，GitHub资料用于说明该平台工作流，主干开发资料代表其作者体系的实践建议；同源文档不当作多次独立效果验证。

  1. Pro Git：Branching Workflows，主题分支与长期分支的组织方式。
  2. GitHub：GitHub flow，轻量分支、审查与合并工作流。
  3. Git：git-switch，新建/切换分支、未提交修改与上游配置。
  4. Git：git-fetch，获取远端引用及refspec行为。
  5. Git：git-branch，分支创建及删除条件。
  6. Git：git-worktree，额外工作树与分支占用限制。
  7. Git：git-merge，合并及冲突处理语义。
  8. GitHub：About protected branches，托管平台的审查与状态检查约束。
  9. Trunk Based Development：Short-Lived Feature Branches，短期分支与及时集成的实践观点，不作为所有团队统一的数量规则。