Git 分支设计规范

Posted 2022-01-27 新亮笔记

为主分支，用于部署到正式环境（PRO），一般由 release 或 hotfix  分支合并，为预上线分支，用于部署到预上线环境（UAT），始终保持与 master 分支一致，一般由 develop 或 hotfix 分支合并，不建议直接在 release 分支上直接修改代码。

如果在 release 分支测试出问题，需要回归验证 develop 分支看否存在此问题。

hotfix 分支

hotfix 为紧急修复分支，命名规则为 hotfix- 开头。

当线上出现紧急问题需要马上修复时，需要基于 release 或 master 分支创建 hotfix 分支，修复完成后，再合并到 release 或 develop 分支，一旦修复上线，便将其删除。

develop 分支

develop 为测试分支，用于部署到测试环境（FAT），始终保持最新完成以及 bug 修复后的代码，可根据需求大小程度确定是由 feature 分支合并，还是直接在上面开发。

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

feature 分支

feature 为需求开发分支，命名规则为 feature- 开头，一旦该需求上线，便将其删除。

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

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

如果 存在 未测试完毕的需求，就基于 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 “挑拣”提交

表示 动作类型，可分为：

fix：修复 xxx Bug

feat：新增 xxx 功能

test：调试 xxx 功能

style：变更 xxx 代码格式或注释

docs：变更 xxx 文档

refactor：重构 xxx 功能或方法

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

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

小结

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

推荐阅读

API 接口设计规范

一线技术管理者究竟在管什么事？

一个人被提拔，不仅仅是能力，而是信任

您必须知道的 Git 分支开发规范

juejin.im/post/5b4328bbf265da0fa21a6820

Git 是目前最流行的源代码管理工具。为规范开发，保持代码提交记录以及 git 分支结构清晰，方便后续维护，现规范 git 的相关操作。

分支管理

分支命名

master 分支

• master 为主分支，也是用于部署生产环境的分支，确保master分支稳定性

• master 分支一般由develop以及hotfix分支合并，任何时间都不能直接修改代码

develop 分支

• develop 为开发分支，始终保持最新完成以及bug修复后的代码

• 一般开发的新功能时，feature分支都是基于develop分支下创建的

feature 分支

• 开发新功能时，以develop为基础创建feature分支

• 分支命名: feature/ 开头的为特性分支， 命名规则: feature/user_module、 feature/cart_module

merge 合并(程序汪公司合并分支就靠它)

 开发分支（dev）上的代码达到上线的标准后，要合并到 master 分支

git checkout devgit pullgit checkout mastergit merge devgit push -u origin master

release分支

• release 为预上线分支，发布提测阶段，会release分支代码为基准提测

当有一组feature开发完成，首先会合并到develop分支，进入提测时，会创建release分支。
如果测试过程中若存在bug需要修复，则直接由开发者在release分支修复并提交。
当测试完成之后，合并release分支到master和develop分支，此时master为最新代码，用作上线。

hotfix 分支

• 分支命名: hotfix/ 开头的为修复分支，它的命名规则与 feature 分支类似

• 线上出现紧急问题时，需要及时修复，以master分支为基线，创建hotfix分支，修复完成后，需要合并到master分支和develop分支

常见任务

增加新功能

(dev)$: git checkout -b feature/xxx            # 从dev建立特性分支
(feature/xxx)$: blabla                         # 开发
(feature/xxx)$: git add xxx
(feature/xxx)$: git commit -m 'commit comment'
(dev)$: git merge feature/xxx --no-ff          # 把特性分支合并到dev

修复紧急bug

(master)$: git checkout -b hotfix/xxx         # 从master建立hotfix分支
(hotfix/xxx)$: blabla                         # 开发
(hotfix/xxx)$: git add xxx
(hotfix/xxx)$: git commit -m 'commit comment'
(master)$: git merge hotfix/xxx --no-ff       # 把hotfix分支合并到master，并上线到生产环境
(dev)$: git merge hotfix/xxx --no-ff          # 把hotfix分支合并到dev，同步代码

测试环境代码

(release)$: git merge dev --no-ff             # 把dev分支合并到release，然后在测试环境拉取并测试

生产环境上线

(master)$: git merge release --no-ff          # 把release测试好的代码合并到master，运维人员操作
(master)$: git tag -a v0.1 -m '部署包版本名'  #给版本命名，打Tag

日志规范

在一个团队协作的项目中，开发人员需要经常提交一些代码去修复bug或者实现新的feature。而项目中的文件和实现什么功能、解决什么问题都会渐渐淡忘，最后需要浪费时间去阅读代码。但是好的日志规范commit messages编写有帮助到我们，它也反映了一个开发人员是否是良好的协作者。

编写良好的Commit messages可以达到3个重要的目的：

• 加快review的流程

• 帮助我们编写良好的版本发布日志

• 让之后的维护者了解代码里出现特定变化和feature被添加的原因

目前，社区有多种 Commit message 的写法规范。来自Angular 规范是目前使用最广的写法，比较合理和系统化。如下图：

Commit messages的基本语法

当前业界应用的比较广泛的是 Angular Git Commit Guidelines

https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#-git-commit-guidelines

具体格式为:

<type>: <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

• type: 本次 commit 的类型，诸如 bugfix docs style 等

• scope: 本次 commit 波及的范围

• subject: 简明扼要的阐述下本次 commit 的主旨，在原文中特意强调了几点 1. 使用祈使句，是不是很熟悉又陌生的一个词，来传送门在此 祈使句 2. 首字母不要大写 3. 结尾无需添加标点

• body: 同样使用祈使句，在主体内容中我们需要把本次 commit 详细的描述一下，比如此次变更的动机，如需换行，则使用 |

• footer: 描述下与之关联的 issue 或 break change，详见案例

Type的类别说明：

• feat: 添加新特性

• fix: 修复bug

• docs: 仅仅修改了文档

• style: 仅仅修改了空格、格式缩进、都好等等，不改变代码逻辑

• refactor: 代码重构，没有加新功能或者修复bug

• perf: 增加代码进行性能测试

• test: 增加测试用例

• chore: 改变构建流程、或者增加依赖库、工具等

Commit messages格式要求

# 标题行：50个字符以内，描述主要变更内容
#
# 主体内容：更详细的说明文本，建议72个字符以内。 需要描述的信息包括:
#
# * 为什么这个变更是必须的? 它可能是用来修复一个bug，增加一个feature，提升性能、可靠性、稳定性等等
# * 他如何解决这个问题? 具体描述解决问题的步骤
# * 是否存在副作用、风险? 
#
# 如果需要的化可以添加一个链接到issue地址或者其它文档

参考链接

http://www.ruanyifeng.com/blog/2012/07/git.html
http://ivweb.io/topic/58abda9d2117ae2f4995b4a8
https://segmentfault.com/a/1190000009048911

END

程序汪往期精彩文章包含答案


 
   
   
 

  
    
    
  
 
   
 
  
  
    
    
  
 
   
 
    
 
   
 
   
 
    
 
   
 
  
  
    
    
  
 
   
 
  
 
   
   
 
 
   
   
 

  
    
    
  
 
   
 
    
 
     
(面试题目录推荐)
 
     

 
     
 
     

 
     
 
     

 
     
 
     
 
     
 
     

 
     
 
     

 
    
 
   
 
  
 
   
   
 
 
   
   
 

  
    
    
  

 
   
   
 
 
   
   
 

  
    
    
  
 
   
 
    
 
     
 
      
 
       
 
        
 
         
 
          
 
           
 
            
             
               
               
             

              
                
                
              
 
               
 
                
 
                 
 
                  
 
                   
 
                   
 
                   
 
                    给个[在看]，是对程序汪最大的支持