Git分支命名规范指南

创作时间:

作者:

@小白创作中心

Git分支命名规范指南

引用

CSDN

https://blog.csdn.net/a6864657/article/details/107236221

在软件开发过程中，Git分支管理是至关重要的环节。合理的分支命名规范不仅能帮助团队成员快速理解代码结构，还能提高协作效率，避免因分支混乱导致的问题。本文将详细介绍Git分支的命名规则和提交记录规范，帮助开发者建立良好的版本控制习惯。

一、命名目的

规范开发，保持代码提交记录，容易维护，方便事后算账，不背锅
git分支结构清晰，好上线，一旦出问题，版本可回退

以下是我总结的git 分支命名规范：

主分支 master 主分支，所有提供给用户使用的正式版本，都在这个主分支上发布
开发分支 feature/dev ①供联调与合作开发 ②不能在dev开发
功能分支 feature/20220708_login 基于master分支创建的个人功能分支
测试分支 release/test 测试分支没有问题合并到master分支
修复分支 hotfix/20220708_login_captcha 修复线上代码的bug
发布版本将测试完成的功能打tag号供上线使用例如TAG-2022-08-01_21-03-22

本人命名规范
例如：
feature/20200305_screen
大屏功能
例如：
fixbug/20200424_screen_data_error
修复大屏日期错误
例如：
release/test
测试分支
其它命令规则(自由发挥、见闻知意、且有一定规则即可)

分支命名规则：类型 - 版本号 - 日期 - 功能 feature/v2-20220708-login
Tag命名规则：类型 - 版本号 - 期次号(或日期) TAG-test-v2.0.1-20200212
分支命名规则：类型 - 版本号 - 日期 - bug英文简称 release-v2.0.1-102401 TAG-2022-08-01
Tag命名规则：类型 - 版本号 - 日期 - bug英文简称 - 期次号 hotfix/v2-20220708_login_captcha

二、 git 分支命名规范

master：主分支
①永远是可用的稳定版本，不能直接在该分支上开发
②开发新功能时，永远从master创建一个新的feature-xxx保证和线上代码一致，进行新功能开发(不背锅)
③feature-xxx自测完毕，合并到develop供同事更新代码(自测不因自己代码bug或冲突影响他人开发)
④功能开发完毕，develop进行联调
⑤联调无问题后，合并到test测试使用
⑥测试无问题，在test分支上打上Tag(表示发布版本)
⑦将打有Tag版本上线，线上测试无误后
⑧将Tag版本或者release/test合并到master分支
⑨可以开始迭代下一个版本新功能
develop：开发主分支
①多人合作的开发分支，不能直接在dev开发；
②每个人开发feature-xxx合并develop供同事拉取
③联调完毕推到test分支
feature-xxx：功能开发分支
①基于master 创建分支，以开发时间+功能模块命名如：feature/20220708_login
②功能自测完毕后，先pull一下develop(防冲突)，然后在feature-xxx合并到develop
③每个版本、每个人有自己独立功能分支
fixbug：bug修复分支
①如果线上出现bug，及时修复，基于master创建出的分支
②命名规范：修复时间+bug问题(或功能) 如：fixbug/20220708_lock_release
③功能自测完毕后, 合并到test分支(前提test分支与线上一直，否则创建release辅助分支进行部署测试)
④测试完毕后，打上Tag号，等待发布
⑤release/test合并到master分支
hotfix-xxx：紧急bug修改分支
同上
release：辅助分支
主分支同 master 分支，预发环境通过之后，上线之前，合并 release 分支(本人厂小，没用预发环境哈)