团队 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三、分支命名规范（强制遵守）

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

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

1. 拉取最新开发代码

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

1. # 切换到 dev 分支
2. git checkout dev
3. # 拉取最新代码
4. git pull origin dev

复制代码

2. 创建个人开发分支

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

1. # 功能开发
2. git checkout -b feature/xxx
3. # bug 修复
4. git checkout -b bugfix/xxx

复制代码

3. 代码提交规范

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

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

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

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

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

1. 创建发布分支

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

1. git checkout dev
2. git pull
3. git checkout -b release/8.4.0.900
4. git push origin release/8.4.0.900

复制代码

2. 代码审阅与测试

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

3. 生产环境上线

使用 release/版本号 分支代码部署生产环境，验证上线成功。
4. 合并 master 并固化版本

• 上线成功后，将发布分支合并到 master 分支（仅管理员操作）
  
• 在 master 分支打 Tag 永久固化版本（回滚唯一依据）
  1. git checkout master
  2. git pull
  3. git merge --no-ff release/8.4.0.900
  4. git tag -a v8.4.0.900 -m "生产上线版本 v8.4.0.900"
  5. git push origin master --tags

  复制代码
• 删除远程及本地发布分支，清理分支环境
  

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

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

• 从 master 分支拉取紧急修复分支：
  1. git checkout master
  2. git pull
  3. git checkout -b hotfix/xxx

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

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

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

八、冲突处理规范

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

九、版本 Tag 规范

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

文档说明

本规范为团队标准 Git 协作流程，所有开发人员必须严格遵守，如有特殊场景需调整，需统一沟通确认后更新文档。
出处：http://www.cnblogs.com/everfight/欢迎转载
来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！