【软件开发规范篇】Git分支使用规范

姑苏老陈

于 2024-04-27 15:49:46 发布

阅读量1.2k

点赞数 23

分类专栏： 30天企业JAVA项目开发实战入门文章标签：分支使用规范分支管理 git分支命名规范

本文链接：https://blog.csdn.net/u012171005/article/details/138250328

版权

49 篇文章 5 订阅

订阅专栏

作者介绍：本人笔名姑苏老陈，从事JAVA开发工作十多年了，带过刚毕业的实习生，也带过技术团队。最近有个朋友的表弟，马上要大学毕业了，想从事JAVA开发工作，但不知道从何处入手。于是，产生了写一个博客专栏想法，介绍当前互联网企业JAVA项目开发如何快速入门。

本文收录于《30天企业JAVA项目开发实战入门》专栏，该专栏内容以当前互联网软件企业中的项目实战为线索，介绍企业JAVA项目开发中涉及到的开发流程、技术、工具、规范要求等等。帮助想从事JAVA开发的大学生或新人，更快的、更好的入门JAVA后端开发工作。

本文介绍一下软件开发过程中，Git分支使用规范。

在团队开发中，遵循一个合理、清晰的 Git 使用流程，是非常重要的。否则，各种不清晰的分支结构，后续产品迭代或维护都会让人很头疼。

几乎所有的版本控制系统都以某种形式支持分支。使用分支意味着你可以把你的工作从开发主线上分离开来，以免影响开发主线。

有人把 Git 的分支模型称为它的“必杀技特性”，因为基于指针的实现使其足够轻量。

Git 鼓励在工作流程中频繁地使用分支与合并，哪怕一天之内进行许多次，但仍要遵循一定的规范。

Git工作流程图：
在这里插入图片描述

开发过程主要存在以下分支：

master

- master主分支始终保持稳定的可发布版本，所以一般不允许直接在该分支上修改代码；
- 只有项目组主程才拥有master主分支的管理权限（例如其他分支合并到master必须由主程操作）；

dev

- dev为开发分支，要能保证能运行, 不能编译错误；
- 始终保持最新完成以及bug修复后的代码；
- 一般开发新功能时，feature 分支都是基于 develop分支下创建的；

hotfix

- 建议格式为hotfix-[问题名称 | bug编号]；
- 线上出现紧急问题时，需要及时修复，以 master 分支为基线，创建 hotfix 分支，修复完成后，需要合并到master 分支和 dev 分支；

feature

- 建议格式为feature_yyyyMMdd_需求名；
- 开发新功能时，以dev分支为基础创建 feature 分支；
- 如果有codereview, 应由一人审核后合并至dev；

bugfix

- 建议格式为bugfix-[bug编号]；
- 从dev分支创建，用于修改测试提出的bug，修复以后，在远程发起向dev分支的合并请求，合并以后删除该分支；

refactor

- 建议格式为refactor-[重构名称]；
- 从dev分支创建，用于代码的**重大规模重构**（小规模重构创建feature分支即可）；
- 重构以后，必须经过严格测试通过，才能向dev分支合并；

需求分类(中长期需求, 跨版本需求等);
由专人按统一的命名格式, 切分支;
各人拉取各自分支开发;
开发完后, 提交代码
(1)若有codeview, 由专人浏览后合并到dev;
(2)若没有, 则自行同步dev上的最新代码到本分支, 然后合并本分支代码到dev(规避代码覆盖问题);
分支开发的时间过久, 则需要定时拉取dev分支到自己业务分支上, 减少后续解决冲突的工作量；
如果测试过程中存在 bug 需要修复，则由开发者在dev上拉取bugfix分支修改bug，完成后合并到dev分
支上；
dev分支的代码测试没有问题, 合并到master, master分支打好tag或做好备份, 通知运维准备上线；
若开发中突遇紧急bug, 需从master上拉取最新代码到本地称为hotfix分支, 改完测试后合并到master分支，通知运维发布。

以上规范不一定是必须的，一般是根据实际情况来的，总结如下：

关注