这篇文章介绍了团队 Git 开发协作规范指引，分享给大家做个参考，收藏极客资料网收获更多编程知识

团队 Git 开发协作规范指引

一、文档目的

统一团队 Git 分支管理、代码提交、合并及发布流程，规范多人协作模式，保证代码可追溯、分支清晰、生产环境稳定，降低协作冲突与线上风险。

二、核心分支定义（固定不可修改）

分支名称	类型	作用	权限控制
master	生产稳定分支	存放已上线、可直接部署的生产代码，永远保持稳定	1. 禁止直接提交/推送 2. 仅管理员可合并发布分支 3. 必须打 Tag 固化版本
dev	开发主分支	日常开发核心分支，所有功能、bug 修复最终汇聚于此	1. 禁止直接提交代码 2. 仅通过 PR 合并个人分支 3. 开发人员可拉取、发起合并
release/版本号	发布分支	预发布、测试专用分支（如 release/8.4.0.900）	1. 仅从 dev 合并代码 2. 禁止直接开发 3. 上线后合并 master 并删除
feature/功能名	功能分支	开发新功能使用（个人临时分支）	开发人员自行创建、开发，完成后删除
bugfix/问题编号	缺陷修复分支	修复测试/开发环境 bug 使用（个人临时分支）	开发人员自行创建、开发，完成后删除
hotfix/问题描述	生产紧急修复分支	仅用于线上生产环境紧急 bug修复	仅核心开发创建，必须同步合并到 dev 和 master

三、分支命名规范（强制遵守）

1. 功能分支：feature/xxx（例：feature/user-login、feature/pay-module）
2. bug 修复分支：bugfix/xxx（例：bugfix/1001-login-error、bugfix/2002-pay-fail）
3. 发布分支：release/版本号（例：release/8.4.0.900、release/8.5.0.100）
4. 生产紧急修复：hotfix/xxx（例：hotfix/crash-fix、hotfix/data-error）

四、标准开发流程（日常功能开发）

1. 拉取最新开发代码

每次开发前，必须同步最新 dev 分支代码，避免冲突：

# 切换到 dev 分支
git checkout dev
# 拉取最新代码
git pull origin dev

2. 创建个人开发分支

禁止直接在 dev 分支开发，必须从最新 dev 拉取个人分支：

# 功能开发
git checkout -b feature/xxx
# bug 修复
git checkout -b bugfix/xxx

3. 代码提交规范

• 提交信息清晰明了，格式：类型: 描述
• 示例：
  • feature: 完成用户登录功能
  • bugfix: 修复登录验证码失效问题
• 小功能多次提交，禁止一次性超大提交

4. 发起合并请求（PR/MR）

开发完成后，推送个人分支到远程，发起 PR（合并请求） 合并到 dev 分支：

1. 推送个人分支：git push origin 分支名
2. 在代码仓库（GitLab/GitHub/Gitee）发起合并请求
3. 分配同事/组长进行代码审阅，审阅通过后方可合并
4. 合并完成后，删除本地及远程个人临时分支

五、版本发布流程（预发布→上线→固化）

1. 创建发布分支

从 dev 分支创建发布分支，用于测试、预发布：

git checkout dev
git pull
git checkout -b release/8.4.0.900
git push origin release/8.4.0.900

2. 代码审阅与测试

1. 发布分支仅用于测试、修复发布阻塞问题，禁止新增功能
2. 测试过程中发现 bug，直接在发布分支修复，修复后同步合并回 dev
3. 必须经过代码审阅，确认无问题后才能准备上线

3. 生产环境上线

使用 release/版本号 分支代码部署生产环境，验证上线成功。

4. 合并 master 并固化版本

1. 上线成功后，将发布分支合并到 master 分支（仅管理员操作）
2. 在 master 分支打 Tag 永久固化版本（回滚唯一依据）

   git checkout master
   git pull
   git merge --no-ff release/8.4.0.900
   git tag -a v8.4.0.900 -m "生产上线版本 v8.4.0.900"
   git push origin master --tags
   

3. 删除远程及本地发布分支，清理分支环境

六、生产环境紧急修复流程

仅用于线上已发布版本出现紧急 bug，禁止常规开发使用：

1. 从 master 分支拉取紧急修复分支：

   git checkout master
   git pull
   git checkout -b hotfix/xxx
   

2. 修复 bug 并测试通过
3. 先合并到 dev 分支，保证开发代码同步修复
4. 再合并到 master 分支，打新 Tag 上线
5. 合并完成后删除紧急修复分支

七、强制规则与禁忌（红线要求）

1. 禁止直接提交：master、dev 分支禁止直接提交、强制推送代码
2. 禁止跨分支开发：所有个人分支必须从 dev 创建，发布分支必须从 dev 创建
3. 禁止跳过审阅：dev→release、release→master 必须经过代码审阅
4. 禁止保留废弃分支：个人分支、发布分支、修复分支使用完成后必须删除
5. 禁止在发布分支开发功能：发布分支仅用于测试和修复阻塞问题

八、冲突处理规范

1. 合并前先拉取目标分支最新代码，本地解决冲突后再提交
2. 冲突代码必须与相关开发人员确认，禁止随意覆盖他人代码
3. 冲突解决完成后，重新提交并发起审阅

九、版本 Tag 规范

• 格式：v主版本.次版本.修订号.发布序号
• 示例：v8.4.0.900、v8.5.0.100
• 每次合并到 master 必须打 Tag，作为版本回溯、回滚的唯一标识

---

文档说明

本规范为团队标准 Git 协作流程，所有开发人员必须严格遵守，如有特殊场景需调整，需统一沟通确认后更新文档。

文章来源:https://www.cnblogs.com/everfight/p/19805285
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若内容造成侵权/违法违规/事实不符，请联系邮箱：jacktools123@163.com进行投诉反馈，一经查实，立即删除！