针对研发、测试、生产环境，以下是常见的 Git 分支命名策略和实践：
一、基于 Git Flow 的标准模型（经典）
|
1
2
3
4
5
|
master -- 生产环境（稳定版本）
├── hotfix/* -- 生产紧急修复分支
release/* -- 测试环境分支（预发布）
develop -- 研发环境（集成开发分支）
├── feature/* -- 功能开发分支
|
具体对应关系：
| 环境 |
分支 |
说明 |
| 生产环境 |
master / main |
生产环境的代码，必须是稳定可发布的 |
| 测试环境 |
release/* (如 release/v1.2.0) |
专门用于测试的分支，从 develop 拉出 |
| 研发环境 |
develop |
日常开发集成环境 |
| 功能开发 |
feature/* (如 feature/user-auth) |
从 develop 拉出，开发完成后合并回 develop |
| 紧急修复 |
hotfix/* (如 hotfix/login-bug) |
从 master 拉出，修复后合并回 master 和 develop |
工作流程：
- 新功能：feature/* → develop (研发环境)
- 测试：develop → release/* (测试环境)
- 上线：release/* → master (生产环境)
- 紧急修复：hotfix/* → master (生产环境) + develop (研发环境)
二、基于 GitHub/GitLab Flow 的简化模型（现代推荐）
|
1
2
3
4
|
main/master -- 生产环境
├── staging -- 测试环境分支（可选）
├── develop -- 研发环境分支（可选）
└── feature/* -- 功能分支
|
环境与分支对应：
| 环境 |
分支 |
说明 |
| 生产环境 |
main / master |
直接对应生产，每次合并都应该是可发布的 |
| 测试环境 |
staging / test |
专门用于测试的分支，从 main 拉出或定期同步 |
| 研发环境 |
develop (可选) |
集成环境，功能分支合并到此进行初步验证 |
| 功能分支 |
feature/xxx, fix/xxx |
所有开发都在独立分支进行 |
特点：
- 更简单直观
- 功能分支通过 Pull Request 直接合并到 main
- 可使用环境分支或通过 CI/CD 自动部署不同环境
三、实际项目中的常见实践
方案 A：三环境独立分支
|
1
2
3
4
|
# 分支结构
main/master # 生产环境
staging # 测试环境（预发布）
develop # 研发环境（日常集成）
|
方案 B：基于标签/提交的部署
|
1
2
3
4
5
6
7
|
# 分支结构
main/master # 主线分支
feature/* # 功能分支
# 通过Git标签区分环境
git tag -a v1.0.0-prod -m "生产环境发布"
git tag -a v1.0.0-staging -m "测试环境"
|
方案 C：环境特定分支前缀
|
1
2
3
4
|
# 分支命名约定
env/production/xxx # 生产环境相关配置
env/staging/xxx # 测试环境相关配置
env/development/xxx # 研发环境相关配置
|
四、推荐的分支命名规范
1.功能分支（研发阶段）
|
1
2
3
|
feature/user-authentication # 用户认证功能
feature/add-payment-method # 添加支付方式
feat/search-optimization # 搜索优化
|
2.修复分支
|
1
2
3
|
fix/login-page-crash # 登录页面崩溃修复
bugfix/memory-leak # 内存泄漏修复
hotfix/critical-security # 紧急安全修复
|
3.发布分支（测试阶段）
|
1
2
|
release/v1.2.0 # 版本1.2.0发布分支
release/2024-03-update # 2024年3月更新
|
4.环境配置分支
|
1
2
3
|
config/production # 生产环境配置
config/staging # 测试环境配置
config/development # 研发环境配置
|
五、最佳实践建议
1.团队约定优先
|
1
2
3
4
5
6
7
8
|
# 在项目README或CONTRIBUTING.md中明确约定
# .git分支策略文档示例：
├── main # 生产环境，保护分支
├── staging # 测试环境，自动部署
├── develop # 研发环境，持续集成
├── feature/[ticket-id]-[description] # 功能分支
├── fix/[ticket-id]-[description] # 修复分支
└── release/v[version] # 发布分支
|
2.CI/CD集成示例
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
|
# .gitlab-ci.yml 或 GitHub Actions 配置示例
stages:
- build
- test
- deploy
# 自动部署到不同环境
deploy_to_development:
stage: deploy
script: ./deploy.sh development
only:
- develop # 合并到develop时部署到研发环境
deploy_to_staging:
stage: deploy
script: ./deploy.sh staging
only:
- staging # 合并到staging时部署到测试环境
- /^release/.*$/ # 或发布分支
deploy_to_production:
stage: deploy
script: ./deploy.sh production
only:
- main # 合并到main时部署到生产环境
- tags # 或打标签时部署
|
3.分支保护规则
- main/master: 强制代码审查、要求CI通过、禁止直接push
- staging: 强制代码审查、要求自动化测试通过
- develop: 要求基本检查通过
六、总结推荐方案
对于大多数中小型项目，推荐以下简单有效的方案：
|
1
2
3
4
5
6
7
8
9
|
# 核心分支
main/master # 生产环境（保护分支）
staging # 测试环境（预发布）
develop # 研发环境（可选，如不用则功能分支直接到staging）
# 临时分支
feature/* # 功能开发
fix/* # 问题修复
hotfix/* # 生产紧急修复
|
使用流程：
- 从 main 创建 feature/xxx 分支开发
- 开发完成后，创建 PR 合并到 staging（测试环境）
- 测试通过后，创建 PR 合并到 main（生产环境）
- 生产发现问题，从 main 创建 hotfix/xxx，修复后合并回 main 和 staging
这样的结构清晰、简单，适合 CI/CD 自动化流程。最重要的是团队统一约定并严格执行。
|
