85人参与 • 2026-02-12 • 其他编程
针对研发、测试、生产环境,以下是常见的 git 分支命名策略和实践:
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 (研发环境)main/master -- 生产环境 ├── staging -- 测试环境分支(可选) ├── develop -- 研发环境分支(可选) └── feature/* -- 功能分支
| 环境 | 分支 | 说明 |
|---|---|---|
| 生产环境 | main / master | 直接对应生产,每次合并都应该是可发布的 |
| 测试环境 | staging / test | 专门用于测试的分支,从 main 拉出或定期同步 |
| 研发环境 | develop (可选) | 集成环境,功能分支合并到此进行初步验证 |
| 功能分支 | feature/xxx, fix/xxx | 所有开发都在独立分支进行 |
特点:
main# 分支结构 main/master # 生产环境 staging # 测试环境(预发布) develop # 研发环境(日常集成)
# 分支结构 main/master # 主线分支 feature/* # 功能分支 # 通过git标签区分环境 git tag -a v1.0.0-prod -m "生产环境发布" git tag -a v1.0.0-staging -m "测试环境"
# 分支命名约定 env/production/xxx # 生产环境相关配置 env/staging/xxx # 测试环境相关配置 env/development/xxx # 研发环境相关配置
feature/user-authentication # 用户认证功能 feature/add-payment-method # 添加支付方式 feat/search-optimization # 搜索优化
fix/login-page-crash # 登录页面崩溃修复 bugfix/memory-leak # 内存泄漏修复 hotfix/critical-security # 紧急安全修复
release/v1.2.0 # 版本1.2.0发布分支 release/2024-03-update # 2024年3月更新
config/production # 生产环境配置 config/staging # 测试环境配置 config/development # 研发环境配置
# 在项目readme或contributing.md中明确约定 # .git分支策略文档示例: ├── main # 生产环境,保护分支 ├── staging # 测试环境,自动部署 ├── develop # 研发环境,持续集成 ├── feature/[ticket-id]-[description] # 功能分支 ├── fix/[ticket-id]-[description] # 修复分支 └── release/v[version] # 发布分支
# .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 # 或打标签时部署
对于大多数中小型项目,推荐以下简单有效的方案:
# 核心分支 main/master # 生产环境(保护分支) staging # 测试环境(预发布) develop # 研发环境(可选,如不用则功能分支直接到staging) # 临时分支 feature/* # 功能开发 fix/* # 问题修复 hotfix/* # 生产紧急修复
使用流程:
main 创建 feature/xxx 分支开发staging(测试环境)main(生产环境)main 创建 hotfix/xxx,修复后合并回 main 和 staging这样的结构清晰、简单,适合 ci/cd 自动化流程。最重要的是团队统一约定并严格执行。
到此这篇关于一些常见的git分支命名策略和实践指南的文章就介绍到这了,更多相关git分支命名策略和实践内容请搜索代码网以前的文章或继续浏览下面的相关文章希望大家以后多多支持代码网!
您想发表意见!!点此发布评论
版权声明:本文内容由互联网用户贡献,该文观点仅代表作者本人。本站仅提供信息存储服务,不拥有所有权,不承担相关法律责任。 如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至 2386932994@qq.com 举报,一经查实将立刻删除。
发表评论