Git多分支规范

Mon, 18 May 2026 08:17:27 +0000

一、什么是Git分支管理？
Git分支管理是指在Git版本控制系统中，通过创建和管理多个分支来组织代码开发流程，支持并行开发、代码隔离和版本控制。
简单说，就像一棵树的主干和分支，master分支是主干，feature分支是枝叶，每个分支都可以独立生长，最后再合并到主干。
其核心作用包括：

• 并行开发：多个功能可以同时开发而不相互干扰。

• 代码隔离：开发分支、测试分支、生产分支相互隔离。

• 版本管理：支持版本回退、热修复和发布管理。

• 团队协作：多人协作时减少代码冲突。

二、分支类型说明
2.1 长期存在分支（核心基础分支）
master 主分支

• 定位：生产环境分支，存放已发布的稳定、可靠版本代码。

• 核心规则：仅用于发布新版本，禁止直接修改或提交新功能。

develop 开发分支

• 定位：日常开发主分支，汇总当前所有正在推进的功能和任务。

• 核心规则：所有新功能开发、改进、优化均从该分支发起，完成后最终合并回此分支。

2.2 临时创建分支（辅助开发/发布分支，完成后删除）
feature 功能分支

• 创建来源：从 develop 分支创建，功能分支的名字，可以采用feature-*的形式命名

• 用途：单独开发某一个新功能（一个功能对应一个分支）

• 流转终点：功能实现、测试完成后，合并回 develop 分支

release 发布分支（不一定用）

• 创建来源：从 develop 分支创建

• 用途：为即将发布的版本做最终准备，仅开展测试、bug修复、文档检查等工作（不新增功能）

• 流转终点：准备完成且测试通过后，同时合并回 master 分支（作为新发布版本）和 develop 分支（同步发布前的修复内容）

hotfix 紧急修复分支

• 创建来源：从 master 分支创建

• 用途：紧急修复生产环境（master 分支对应版本）中出现的问题

• 流转终点：修复完成后，同时合并回 master 分支（更新生产版本）和 develop 分支（同步修复内容，避免后续版本复现问题）

三、业务流程图
sequenceDiagram
    participant M as Master分支
    participant D as Develop分支
    participant F as Features功能分支
    participant B as Bugfix缺陷分支
    participant DT as 开发测试环境
    participant PT as 生产测试环境
    %% 功能开发流程（标注关键测试节点）
    note over M,D: 功能开发阶段
    M->>D: 从master初始化develop分支
    D->>F: 基于develop创建功能分支
    F->>DT: 开发完成→直接发布到开发测试环境（第一轮测试）
    note over F,DT: 开发联调阶段
    DT->>F: 反馈联调问题
    F->>F: 在功能分支修复问题
    F->>D: 修复完成→合并到develop分支
    D->>DT: 合并后→再次发布到开发测试环境（第二轮验证）
    DT->>F: 开发测试通过
    F->>M: 功能分支合并到master分支
    M->>PT: master发布到生产测试环境
    %% 缺陷修复流程（标注合并develop再测试）
    note over M,PT: 缺陷修复阶段
    PT->>M: 反馈生产测试缺陷问题
    M->>B: 基于master创建Bugfix缺陷分支
    B->>B: 在Bugfix分支修复缺陷问题
    B->>D: Bugfix分支→合并缺陷修复到develop
    D->>DT: 合并后→发布到开发测试环境联调
    DT->>D: 缺陷联调测试通过
    D->>M: develop→合并缺陷修复到master
    M->>PT: master再次发布到生产测试验收
    M->>M: 验收通过，创建版本标签

四、常见分支策略

• master：生产环境代码，标签标记版本

• develop：开发主分支，集成功能分支

• feature：功能开发分支，从develop创建

• release：发布准备分支，从develop/master创建

• hotfix：紧急修复分支，从master创建

五、分支命名规范

• 功能分支：feature/功能名称或 feature/issue-id-功能描述

• 发布分支：release/v1.2.0 或 release/2027-01-01

• 热修复分支：hotfix/bug-id 或 hotfix/紧急修复描述

• 开发分支：develop 或 development

六、互联网大厂Git工作流实战 devops

七、分支管理最佳实践

• 分支生命周期管理：及时删除已合并的分支

• 保护主分支：通过分支保护规则防止直接推送
• 代码审查：所有合并都需要Pull Request和审查
• 定期同步：保持分支与主分支的同步

• 标签管理：重要版本打tag标记

八、Git多分支实战和代码合并规范讲解
8.1 Git分支基本操作实战
# 查看当前分支
git branch
# 创建新分支（基于当前分支）
git branch feature/user-login
# 创建并切换到新分支
git checkout -b feature/user-login
# 基于指定分支创建新分支
git checkout -b feature/payment develop
# 查看所有分支（包括远程）
git branch -a
8.2 分支工作流完整演练
功能开发工作流
# 1. 从develop分支创建功能分支
git checkout develop
git pull origin develop
git checkout -b feature/user-registration
# 2. 开发功能并提交
# ... 开发代码 ...
git add .
git commit -m "feat: 增加用户注册功能"
# 3. 推送分支到远程
git push origin feature/user-registration
# 4. 创建Pull Request/Merge Request
# 在GitHub/GitLab上创建PR
# 5. 同步最新代码
git checkout develop
git pull origin develop
git checkout feature/user-registration
# 6. 解决可能的冲突
# ... 解决冲突 ...
# 7. 推送更新后的分支
git push origin feature/user-registration --force-with-lease
紧急修复工作流
# 1. 从master创建热修复分支
git checkout master
git pull origin master
git checkout -b hotfix/critical-bug-fix
# 2. 修复bug
# ... 修复代码 ...
git add .
git commit -m "fix: 解决严重的授权问题"
# 3. 同时合并到master和develop
git checkout master
git merge hotfix/critical-bug-fix
git push origin master
git checkout develop
#将热修复代码合并到develop分支，同步修复逻辑到开发分支。
git merge hotfix/critical-bug-fix
git push origin develop
# 4. 删除热修复分支
git branch -d hotfix/critical-bug-fix
代码合并规范说明
提交信息规范
# 格式：type(scope): description
git commit -m "feat(授权): 增加JWT授权验证"
# 常用type：
# feat: 新功能
# fix: 修复bug
# docs: 文档更新
# style: 代码格式调整
# refactor: 代码重构
# test: 测试相关
分支命名规范

• 功能分支：feature/功能名称或 feature/issue-123-user-login

• 修复分支：fix/bug描述或 fix/issue-456-data-validation

• 发布分支：release/v1.2.0

• 热修复：hotfix/紧急修复描述

合并请求规范
• 标题清晰描述变更内容

• 详细描述变更原因和影响

• 关联相关issue或需求

• 提供测试说明和验证步骤

一、什么是Git分支管理？

Git分支管理是指在Git版本控制系统中，通过创建和管理多个分支来组织代码开发流程，支持并行开发、代码隔离和版本控制。

简单说，就像一棵树的主干和分支，master分支是主干，feature分支是枝叶，每个分支都可以独立生长，最后再合并到主干。

其核心作用包括：

并行开发：多个功能可以同时开发而不相互干扰。
代码隔离：开发分支、测试分支、生产分支相互隔离。
版本管理：支持版本回退、热修复和发布管理。
团队协作：多人协作时减少代码冲突。

二、分支类型说明

2.1 长期存在分支（核心基础分支）

master 主分支

定位：生产环境分支，存放已发布的稳定、可靠版本代码。
核心规则：仅用于发布新版本，禁止直接修改或提交新功能。

develop 开发分支

定位：日常开发主分支，汇总当前所有正在推进的功能和任务。
核心规则：所有新功能开发、改进、优化均从该分支发起，完成后最终合并回此分支。

2.2 临时创建分支（辅助开发/发布分支，完成后删除）

feature 功能分支

创建来源：从 develop 分支创建，功能分支的名字，可以采用feature-*的形式命名
用途：单独开发某一个新功能（一个功能对应一个分支）
流转终点：功能实现、测试完成后，合并回 develop 分支

release 发布分支（不一定用）

创建来源：从 develop 分支创建
用途：为即将发布的版本做最终准备，仅开展测试、bug修复、文档检查等工作（不新增功能）
流转终点：准备完成且测试通过后，同时合并回 master 分支（作为新发布版本）和 develop 分支（同步发布前的修复内容）

hotfix 紧急修复分支

创建来源：从 master 分支创建
用途：紧急修复生产环境（master 分支对应版本）中出现的问题
流转终点：修复完成后，同时合并回 master 分支（更新生产版本）和 develop 分支（同步修复内容，避免后续版本复现问题）

三、业务流程图

sequenceDiagram     participant M as Master分支     participant D as Develop分支     participant F as Features功能分支     participant B as Bugfix缺陷分支     participant DT as 开发测试环境     participant PT as 生产测试环境     %% 功能开发流程（标注关键测试节点）     note over M,D: 功能开发阶段     M->>D: 从master初始化develop分支     D->>F: 基于develop创建功能分支     F->>DT: 开发完成→直接发布到开发测试环境（第一轮测试）     note over F,DT: 开发联调阶段     DT->>F: 反馈联调问题     F->>F: 在功能分支修复问题     F->>D: 修复完成→合并到develop分支     D->>DT: 合并后→再次发布到开发测试环境（第二轮验证）     DT->>F: 开发测试通过     F->>M: 功能分支合并到master分支     M->>PT: master发布到生产测试环境     %% 缺陷修复流程（标注合并develop再测试）     note over M,PT: 缺陷修复阶段     PT->>M: 反馈生产测试缺陷问题     M->>B: 基于master创建Bugfix缺陷分支     B->>B: 在Bugfix分支修复缺陷问题     B->>D: Bugfix分支→合并缺陷修复到develop     D->>DT: 合并后→发布到开发测试环境联调     DT->>D: 缺陷联调测试通过     D->>M: develop→合并缺陷修复到master     M->>PT: master再次发布到生产测试验收     M->>M: 验收通过，创建版本标签

四、常见分支策略

master：生产环境代码，标签标记版本
develop：开发主分支，集成功能分支
feature：功能开发分支，从develop创建
release：发布准备分支，从develop/master创建
hotfix：紧急修复分支，从master创建

五、分支命名规范

功能分支：feature/功能名称或 feature/issue-id-功能描述
发布分支：release/v1.2.0 或 release/2027-01-01
热修复分支：hotfix/bug-id 或 hotfix/紧急修复描述
开发分支：develop 或 development

六、互联网大厂Git工作流实战 devops

七、分支管理最佳实践

分支生命周期管理：及时删除已合并的分支
保护主分支：通过分支保护规则防止直接推送
代码审查：所有合并都需要Pull Request和审查
定期同步：保持分支与主分支的同步
标签管理：重要版本打tag标记

八、Git多分支实战和代码合并规范讲解

8.1 Git分支基本操作实战

# 查看当前分支 git branch  # 创建新分支（基于当前分支） git branch feature/user-login  # 创建并切换到新分支 git checkout -b feature/user-login  # 基于指定分支创建新分支 git checkout -b feature/payment develop  # 查看所有分支（包括远程） git branch -a

8.2 分支工作流完整演练

功能开发工作流

# 1. 从develop分支创建功能分支 git checkout develop git pull origin develop git checkout -b feature/user-registration  # 2. 开发功能并提交 # ... 开发代码 ... git add . git commit -m "feat: 增加用户注册功能"  # 3. 推送分支到远程 git push origin feature/user-registration  # 4. 创建Pull Request/Merge Request # 在GitHub/GitLab上创建PR  # 5. 同步最新代码 git checkout develop git pull origin develop git checkout feature/user-registration  # 6. 解决可能的冲突 # ... 解决冲突 ...  # 7. 推送更新后的分支 git push origin feature/user-registration --force-with-lease

紧急修复工作流

# 1. 从master创建热修复分支 git checkout master git pull origin master git checkout -b hotfix/critical-bug-fix  # 2. 修复bug # ... 修复代码 ... git add . git commit -m "fix: 解决严重的授权问题"  # 3. 同时合并到master和develop git checkout master git merge hotfix/critical-bug-fix git push origin master git checkout develop  #将热修复代码合并到develop分支，同步修复逻辑到开发分支。 git merge hotfix/critical-bug-fix git push origin develop  # 4. 删除热修复分支 git branch -d hotfix/critical-bug-fix

代码合并规范说明

提交信息规范

# 格式：type(scope): description git commit -m "feat(授权): 增加JWT授权验证"  # 常用type： # feat: 新功能 # fix: 修复bug # docs: 文档更新 # style: 代码格式调整 # refactor: 代码重构 # test: 测试相关

分支命名规范

功能分支：feature/功能名称或 feature/issue-123-user-login
修复分支：fix/bug描述或 fix/issue-456-data-validation
发布分支：release/v1.2.0
热修复：hotfix/紧急修复描述

合并请求规范

标题清晰描述变更内容
详细描述变更原因和影响
关联相关issue或需求
提供测试说明和验证步骤

Tags - git

[评论] Git多分支规范

Thu, 01 Jan 1970 00:00:00 +0000

Heck's Blog