常见的 Git 分支命名策略和实践

针对研发、测试、生产环境，以下是常见的 Git 分支命名策略和实践：

一、基于 Git Flow 的标准模型（经典）

lua 复制代码

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 的简化模型（现代推荐）

lua 复制代码

main/master    -- 生产环境
├── staging    -- 测试环境分支（可选）
├── develop    -- 研发环境分支（可选）
└── feature/*  -- 功能分支

环境与分支对应：

环境	分支	说明
生产环境	`main` / `master`	直接对应生产，每次合并都应该是可发布的
测试环境	`staging` / `test`	专门用于测试的分支，从 `main` 拉出或定期同步
研发环境	`develop` (可选)	集成环境，功能分支合并到此进行初步验证
功能分支	`feature/xxx`, `fix/xxx`	所有开发都在独立分支进行

特点：

更简单直观
功能分支通过 Pull Request 直接合并到 main
可使用环境分支或通过 CI/CD 自动部署不同环境

三、实际项目中的常见实践

方案 A：三环境独立分支

bash 复制代码

# 分支结构
main/master     # 生产环境
staging         # 测试环境（预发布）
develop         # 研发环境（日常集成）

方案 B：基于标签/提交的部署

bash 复制代码

# 分支结构
main/master     # 主线分支
feature/*       # 功能分支

# 通过Git标签区分环境
git tag -a v1.0.0-prod -m "生产环境发布"
git tag -a v1.0.0-staging -m "测试环境"

方案 C：环境特定分支前缀

bash 复制代码

# 分支命名约定
env/production/xxx   # 生产环境相关配置
env/staging/xxx      # 测试环境相关配置
env/development/xxx  # 研发环境相关配置

四、推荐的分支命名规范

1. 功能分支（研发阶段）

bash 复制代码

feature/user-authentication    # 用户认证功能
feature/add-payment-method     # 添加支付方式
feat/search-optimization       # 搜索优化

2. 修复分支

bash 复制代码

fix/login-page-crash           # 登录页面崩溃修复
bugfix/memory-leak             # 内存泄漏修复
hotfix/critical-security       # 紧急安全修复

3. 发布分支（测试阶段）

bash 复制代码

release/v1.2.0                 # 版本1.2.0发布分支
release/2024-03-update         # 2024年3月更新

4. 环境配置分支

bash 复制代码

config/production              # 生产环境配置
config/staging                 # 测试环境配置
config/development             # 研发环境配置

五、最佳实践建议

1. 团队约定优先

bash 复制代码

# 在项目README或CONTRIBUTING.md中明确约定
# .git分支策略文档示例：
├── main                      # 生产环境，保护分支
├── staging                   # 测试环境，自动部署
├── develop                   # 研发环境，持续集成
├── feature/[ticket-id]-[description]  # 功能分支
├── fix/[ticket-id]-[description]      # 修复分支
└── release/v[version]        # 发布分支

2. CI/CD集成示例

yaml 复制代码

# .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: 要求基本检查通过

六、总结推荐方案

对于大多数中小型项目，推荐以下简单有效的方案：

bash 复制代码

# 核心分支
main/master     # 生产环境（保护分支）
staging         # 测试环境（预发布）
develop         # 研发环境（可选，如不用则功能分支直接到staging）

# 临时分支
feature/*       # 功能开发
fix/*           # 问题修复
hotfix/*        # 生产紧急修复

使用流程：

从 main 创建 feature/xxx 分支开发
开发完成后，创建 PR 合并到 staging（测试环境）
测试通过后，创建 PR 合并到 main（生产环境）
生产发现问题，从 main 创建 hotfix/xxx，修复后合并回 main 和 staging

这样的结构清晰、简单，适合 CI/CD 自动化流程。最重要的是团队统一约定并严格执行。