Git 分支设计规范

概述

这篇文章分享 Git 分支设计规范，目的是提供给研发人员做参考。

规范是死的，人是活的，希望自己定的规范，不要被打脸。

在说 Git 分支规范之前，先说下在系统开发过程中常用的环境。

简称	全称
DEV	Development environment
FAT	Feature Acceptance Test environment
UAT	User Acceptance Test environment
PRO	Production environment

• DEV 环境：用于开发者调试使用。
• FAT 环境：功能验收测试环境，用于测试环境下的软件测试者测试使用。
• UAT 环境：用户验收测试环境，用于生产环境下的软件测试者测试使用。
• PRO 环境：就是生产环境。

比如，项目域名为：

http://www.abc.com

，那么相关环境的域名可这样配置：

• DEV 环境：本地配置虚拟域名即可
• FAT 环境：

  http://fat.abc.com

• UAT 环境：

  http://uat.abc.com

• PRO 环境：

  http://www.abc.com

接下来，针对不同的环境来设计分支。

分支

	名称	环境	可访问
master	主分支		是
release	预上线分支
hotfix	紧急修复分支		否
develop	测试分支
feature	需求开发分支

master 分支

master

为主分支，用于部署到正式环境（PRO），一般由

release

或

hotfix

分支合并，任何情况下不允许直接在 master 分支上修改代码。

release 分支

release

为预上线分支，用于部署到预上线环境（UAT），始终保持与

master

分支一致，一般由

develop

hotfix

分支合并，不建议直接在

release

分支上直接修改代码。

如果在

release

分支测试出问题，需要回归验证

develop

分支看否存在此问题。

hotfix 分支

hotfix

为紧急修复分支，命名规则为

hotfix-

开头。

当线上出现紧急问题需要马上修复时，需要基于

release

master

分支创建

hotfix

分支，修复完成后，再合并到

release

develop

分支，一旦修复上线，便将其删除。

develop 分支

develop

为测试分支，用于部署到测试环境（FAT），始终保持最新完成以及 bug 修复后的代码，可根据需求大小程度确定是由

feature

分支合并，还是直接在上面开发。

一定是满足测试的代码才能往上面合并或提交。

feature 分支

feature

为需求开发分支，命名规则为

feature-

开头，一旦该需求上线，便将其删除。

这么说可能有点不容易理解，接下来举几个开发场景。

开发场景

新需求加入

有一个订单管理的新需求需要开发，首先要创建一个

feature-order

分支，问题来了，该分支是基于哪个分支创建？

如果 存在 未测试完毕的需求，就基于

master

创建。

如果 不存在 未测试完毕的需求，就基于

develop

1. 需求在

   feature-order

   分支开发完毕，准备提测时，要先确定

   develop

   不存在未测试完毕的需求，这时研发人员才能将将代码合并到

   develop

   （测试环境）供测试人员测试。
2. 测试人员在

   develop

   （测试环境） 测试通过后，研发人员再将代码发布到

   release

   （预上线环境）供测试人员测试。

3. release

   （预上线环境）测试通过后，研发人员再将代码发布到

   master

   （正式环境）供测试人员测试。

4. master

   (正式环境) 测试通过后，研发人员需要删除

   feature-order

   分支。

普通迭代

有一个订单管理的迭代需求，如果开发工时 < 1d，直接在

develop

开发，如果开发工时 > 1d，那就需要创建分支，在分支上开发。

开发后的提测上线流程 与 新需求加入的流程一致。

修复测试环境 Bug

在

develop

测试出现了Bug，如果修复工时 < 2h，直接在

develop

修复，如果修复工时 > 2h，需要在分支上修复。

修复后的提测上线流程 与 新需求加入的流程一致。

修改预上线环境 Bug

release

测试出现了Bug，首先要回归下

develop

分支是否同样存在这个问题。

如果存在，修复流程 与 修复测试环境 Bug流程一致。

如果不存在，这种可能性比较少，大部分是数据兼容问题，环境配置问题等。

修改正式环境 Bug

master

release

和

develop

如果不存在，这种可能性也比较少，大部分是数据兼容问题，环境配置问题等。

紧急修复正式环境 Bug

需求在测试环节未测试出 Bug，上线运行一段时候后出现了 Bug，需要紧急修复的。

我个人理解紧急修复的意思是没时间验证测试环境了，但还是建议验证下预上线环境。

• 如果

  release

  分支存在未测试完毕的需求，就基于

  master

  创建

  hotfix-xxx

  分支，修复完毕后发布到

  master

  验证，验证完毕后，将

  master

  代码合并到

  release

  develop

  分支，同时删掉

  hotfix-xxx

• release

  分支不存在未测试完毕的需求，但

  develop

  release

  hotfix-xxx

  release

  验证，后面流程与上线流程一致，验证完毕后，将

  master

  develop

  hotfix-xxx

• release

  develop

  分支都不存在未测试完毕的需求， 就直接在

  develop

  分支上修复完毕后，发布到

  release

  验证，后面流程与上线流程一致。

并行提测

在一个项目中并行开发了两个需求，并行提测，但是上线日期不同。

我能想到的两种方案：

• 再部署一套可供测试人员测试的分支
• 使用

  git cherry-pick

  “挑拣”提交

对于并行提测，你有好的方案吗？欢迎留言。

Commit 日志规范

提交信息一定要认真填写！

建议参考规范：

<type>(scope)：<subject>

比如：fix(首页模块)：修复弹窗 JS Bug。

type

表示 动作类型，可分为：

• fix：修复 xxx Bug
• feat：新增 xxx 功能
• test：调试 xxx 功能
• style：变更 xxx 代码格式或注释
• docs：变更 xxx 文档
• refactor：重构 xxx 功能或方法

scope

表示 影响范围，可分为：模块、类库、方法等。

subject

表示 简短描述，最好不要超过 60 个字，如果有相关 Bug 的 Jira 号，建议在描述中加上。

小结

暂时就想到这么多，规范这东西不是一成不变的，供参考。

推荐阅读

• API 接口设计规范
• 一线技术管理者究竟在管什么事？
• 一个人被提拔，不仅仅是能力，而是信任

作者：新亮笔记（关注公众号，可申请添加微信好友）

出处：https://www.cnblogs.com/xinliangcoder

本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。