【软件开发规范篇】Git分支使用规范_代码库分支开发规范

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

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

一、前言

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

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

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

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

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

Git工作流程图：

二、分支命名管理

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

• master
• dev
• hotfix-[问题名称 | bug编号]
• feature-yyyyMMdd_需求名称
• bugfix-[bug编号]
• refactor-[重构名称]

master

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

dev

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

hotfix

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

feature

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

bugfix

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

refactor

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

三、分支操作流程

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

四、总结

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

• 自己的分支一定要自测，切记不要提交后，影响到其他代码，更别说别人拉下代码还报错这种低级错误；
• 本地分支要做到勤提交，分小功能提交，一次提交一大堆各种功能的做法也要杜绝；
• 每天第一件事就是更新 develop 分支内容到本地分支，避免大规模 merge，太容易出错了；
• 迭代新版本时，一定要保证当前开发分支和线上分支一样；