---
title: "Git 什么时候应该创建新分支？从功能开发、Bug 修复到版本维护"
source: https://www.iowill.com/blog/2026/10/when-to-create-git-branch/
date: 2026-10-29
updated: 2026-10-29
tags: [Git, 分支管理, 开发工作流, 版本控制]
categories: [编程开发]
---

# Git 什么时候应该创建新分支？从功能开发、Bug 修复到版本维护

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

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

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

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

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

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

[Pro Git的分支工作流章节](https://git-scm.com/book/en/v2/Git-Branching-Branching-Workflows)介绍了围绕单一特性或相关工作创建主题分支的做法。[GitHub flow](https://docs.github.com/en/get-started/using-github/github-flow)也采用轻量的分支、审查和合并流程。这两项资料支持任务分支的组织方式，不代表所有项目都必须建立相同的长期分支结构。

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

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

![新建或复用分支的任务边界：只读、补测文档、独立开发、并行任务和紧急修复](https://img.iowill.com/file/编程开发/Git什么时候创建新分支/body1.png)

作者建议示意：以独立目标与验收边界判断，不按文件或提交数量机械划分。

## 分支创建时机与基线选择

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

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

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

```bash
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文档](https://git-scm.com/docs/git-fetch)。`main...origin/main`只展示两者的提交差异，不处理差异。若本地main还有本次必须包含的提交，应明确它们的集成安排，不能默认从origin/main创建分支就已包含这些工作。

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

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

```bash
git switch -c hotfix/session-expiry v1.4.2
```

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

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

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

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

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

## 未提交修改的分支处理

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

```bash
git status --short
git diff
git diff --cached
git switch -c feat/report-export
git status --short
```

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

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

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

## main已有提交的分支处理

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

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

```bash
git branch feat/report-export
git switch feat/report-export
```

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

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

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

## 使用worktree并行处理任务

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

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

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

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

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

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

![同一仓库中的分支历史与独立worktree工作目录，以及运行数据仍需隔离的关系](https://img.iowill.com/file/编程开发/Git什么时候创建新分支/body2.png)

原理示意：worktree隔离工作文件与索引，不自动隔离数据库、账号和端口。

## 分支审核、合并与清理

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

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

同步和合并方式由项目规则决定。Git的[合并文档](https://git-scm.com/docs/git-merge)说明了冲突等行为；创建了任务分支并不意味着合并时不会冲突，也不意味着可以随意rebase共享分支。

[GitHub保护分支文档](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches)提供审查、状态检查等可配置要求。这些是托管平台的保护措施，不能只靠分支命名实现，也不能将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](https://git-scm.com/book/en/v2/Git-Branching-Branching-Workflows)，主题分支与长期分支的组织方式。
2.  [GitHub：GitHub flow](https://docs.github.com/en/get-started/using-github/github-flow)，轻量分支、审查与合并工作流。
3.  [Git：git-switch](https://git-scm.com/docs/git-switch)，新建/切换分支、未提交修改与上游配置。
4.  [Git：git-fetch](https://git-scm.com/docs/git-fetch)，获取远端引用及refspec行为。
5.  [Git：git-branch](https://git-scm.com/docs/git-branch)，分支创建及删除条件。
6.  [Git：git-worktree](https://git-scm.com/docs/git-worktree)，额外工作树与分支占用限制。
7.  [Git：git-merge](https://git-scm.com/docs/git-merge)，合并及冲突处理语义。
8.  [GitHub：About protected branches](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches)，托管平台的审查与状态检查约束。
9.  [Trunk Based Development：Short-Lived Feature Branches](https://trunkbaseddevelopment.com/short-lived-feature-branches/)，短期分支与及时集成的实践观点，不作为所有团队统一的数量规则。