Git 分支设计规范

标签： git 分支 设计 | 发表时间：2020-02-22 00:33 | 作者：訢亮
出处：https://juejin.im/welcome/backend

概述

这篇文章分享 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 主分支 PRO 是
release 预上线分支 UAT 是
hotfix 紧急修复分支 DEV 否
develop 测试分支 FAT 是
feature 需求开发分支 DEV 否

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 测试出现了Bug，首先要回归下 release 和 develop 分支是否同样存在这个问题。

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

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

紧急修复正式环境 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 日志规范

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

建议参考规范： (scope)：

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

type 表示 动作类型，可分为：

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

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

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

小结

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

推荐阅读

相关 [git 分支 设计] 推荐：

Git 分支设计规范

- - 掘金后端
这篇文章分享 Git 分支设计规范，目的是提供给研发人员做参考. 规范是死的，人是活的，希望自己定的规范，不要被打脸. 在说 Git 分支规范之前，先说下在系统开发过程中常用的环境. DEV 环境：用于开发者调试使用. FAT 环境：功能验收测试环境，用于测试环境下的软件测试者测试使用. UAT 环境：用户验收测试环境，用于生产环境下的软件测试者测试使用.

Git分支管理策略

- - 阮一峰的网络日志
如果你严肃对待编程，就必定会使用" 版本管理系统"（Version Control System）. 眼下最流行的"版本管理系统"，非 Git莫属. 相比同类软件，Git有很多优点. 其中很显著的一点，就是版本的分支（branch）和合并（merge）十分方便. 有些传统的版本管理软件，分支操作实际上会生成一份现有代码的物理拷贝，而Git只生成一个指向当前版本（又称"快照"）的指针，因此非常快捷易用.

git分支的管理流程

- - 掘金 后端
这是我参与「掘金日新计划 · 6 月更文挑战」的第2天， 点击查看活动详情. 现在大部分公司都是使用git来管理代码的，我今天分享一下我们司后端代码的git管理流程吧. 先拉取最新的develop分支的代码. 确保develop上一个版本的代码已经合并到test分支了. 基于develop分支创建自己的功能开发分支.

Git 分支管理策略与工作流程

- - IT瘾-dev
Git 是目前世界上最先进的分布式版本控制系统. 它使我们更方便的跟踪，管理和组织代码. 也帮助了我们更好的与其他开发者进行协作开发. 协作开发必须有一个规范来约束各个贡献者的行为. 这个规范就是 Git 工作流程(Git Workflow)，也为我们规范各个分支管理策略等行为. Git 工作流程是有关如何使用 Git 以高效协作开发的规则或策略建议，下文这些常见工作流程只是作为指导参考，这些工作流不是一成不变的，我们应该根据自己的项目选择或制定合适自己的工作流.

Git基础

- Wolf - 潘魏增
上个月末在公司内部作了一次《Git基础》的主题分享. 这里把分享内容公布出来，希望对一些朋友有用. 如果之前没有接触过Git，wikipedia上面已经有非常好的介绍. pdf格式：http://panweizeng.com/download/git-basics-meituan.pdf. keynote格式：http://panweizeng.com/download/git-basics-meituan.key.

Git-rebase 小筆記

- lepture - YORKXIN×YORKXIN
最近剛好有個機會整理很亂的 Git commit tree，終於搞懂了 rebase 的用法，筆記一下. 大家都知道 Git 有個特色就是 branch 開很大開不用錢，但很多 branches 各自開發，總要在適當時機 merge 進去 master. 看過很多 git 操作指南都告訴我們，可以妥善利用 rebase 來整理看似很亂或是中途可能不小心手滑 commit 錯的 commits ，甚至可以讓 merge 產生的線看起來比較簡單，不會有跨好幾十個 commits 的線.

Git 简明教程

- satoru - python.cn(jobs, news)
Git 是一款强大的分布式版本控制系统.在他的官网可以找到已经有很多著名的项目正在使用. Like most other modern version control systems, Git gives each developer a local copy of the entire development history, and changes are copied from one such repository to another.

git架构图解

- - CSDN博客研发管理推荐文章
　　最近又遇到Git了，发现网络上Git的资料确实不咋滴，难懂不全面. 至于Git是什么我就不多说了，相比svn上手确实更难. 与svn集中版本库相比较，Git被称作分布式版本库，在分布式的版本库中任何一个库都可以作为中心库看待. 如果说svn是颗树，那么Git就像一张网. Svn在每个目录都有一个.svn文件夹存放信息，而git只在根目录才有，这就决定了svn可以单独拉取某个子目录或者某个文件，而git需要全部拉取.

科普：Git Commit Guidelines

- - IT瘾-dev
降低Review成本，可以明确知道本次提交的改变和影响. 规范整个Team的提交习惯，对技术素养的养成有益. 可以通过统一工具，抽取规范的message自动形成change log. 目前Github的Angular项目，就是完全采用规范的Git Message来进行日常的提交管理和发布管理的，下面是这个项目的Commit记录，和自动根据commit生成的change log.

一些 Git 設定偏好

- dylan - ihower { blogging }
讓 command line 指令列顯示目前處在哪一個 Git Brnach，最早是在 RGBA 看到這一招，非常方便. 請修改家目錄的 ~/.bashrc 或 ~/.bash_profile 檔案：. 記得打開 Git 的 color 設定，這樣 Git 指令的輸出結果才會加上顏色，像是 git status 等：.