欢迎来到Heck's Blog，专业承接拿站、企业建站、仿站、网上商城架构、门户网站搭建、空间域名注册、软件定制等项目。关注网络安全，因为专注，所以专业，懂得放弃，才能收获。有事请发邮件至i@heckjj.com，请记住本站网址：http://www.heckjj.com，多谢。
5月18
一、什么是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版本控制系统中，通过创建和管理多个分支来组织代码开发流程，支持并行开发、代码隔离和版本控制。
简单说，就像一棵树的主干和分支，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或需求
- 提供测试说明和验证步骤
