研发流程中的git分支管理及角色介绍
# 研发流程中涉及到的角色
- PM(Product Manager) 产品经理,又称品牌经理。写PRD文档的。
- RD(Research and Development engineer) 研发工程师,俗称 Java 猿、PHP猿、GO猿、Python猿。
- QA(Quality Assurance)
- 测试的同学,QA的主要职责就是质量保证工作,属于质量保证部门。
- 大公司都是几个高级QA带着一帮外包QA工作。
- OP(Operator) 运维的同学,搞服务器会算法的大佬。
- FE(Front-End) 前端开发同学,也属于研发部门。
- UE(User Experience)
用户体验,主要研究交互的优不优雅啥的,感觉比
UI
高级。 - UI(User Interface) 用户界面,设计产品原型图的同学。
- DBA(Database Administrator) 数据库管理员,专门研究数据库的大佬。
- SRE(Site Reliability Engineer) 网站可靠性工程师,是软件工程师和系统管理员的结合,一个SRE工程师基本上需要掌握很多知识:算法,数据结构,编程能力,网络编程,分布式系统,可扩展架构,故障排除。
- MRD(Market Requirements Document) 市场需求文档,唯一不用猿们看的文档,因为是PM给老大们看的。
- PRD 产品需求文档,需要猿们经常看的文档。
# 开发过程当中的git分支管理
# 介绍
多人参与开发时的 GIT 分支管理模型,使用的是gitlab来作代码管理与权限控制。
# 服务器部署环境
通常来讲,服务器端分如下几种运行、部署环境
- staging:用于开发功能时给 RD 测试用,代码、数据库都是测试环境的。数据库
- preview:用于代码部署到生产环境前的测试,代码是准生产版本,数据库是生产环境的。
- production:生产环境,代码、数据库都是生产环境的。
以上环境的代码稳定版依次提升。
# 分支种类
为配合以上几种部署环境,代码库分如下几种类型的分支
staging 分支:用于 staging 环境的部署。
master 分支:GIT 的默认分支,提供最新、稳定的代码。
preview 分支:用于 preview 环境的部署。
release 分支:用于 production 环境的部署,保持代码随时可发布到生产环境。
以上几个分支会永久存在于代码库中,在开发功能、修复 BUG 的过程当中,还会用到几种分支。
# 开发新功能时会用到的
dev 分支:
以 dev_xxx 命名。xxx 表示**功能**的简单描述。
feature 分支:
以 feature_xxx 命名,其中,xxx 表示对**子功能**的简单描述。
一个功能会拆成若干个子功能,每一个 RD 开发 1 个子功能。
dev 分支与 feature 分支的区别:
一个新功能一般须要多个 RD 参与开发。RD 在各自的 feature 分支提交代码。存在一种状况,RD B 的代码依赖 RD A,而这个时候两我的写的代码都不稳定,不适合往 master 分支合并。此时,RD A 将本身的代码先合入 dev 分支,RD B 基于 dev 分支进行开发。
修复常规 bug 时会用到的:
bugfix:以 bugfix_xxx 命名。xxx 表示 bug 的简单描述。
修复紧急 bug 时会用到的:
hotfix:以 hotfix_xxx 命名。xxx 表示 bug 的简单描述。
2
3
4
5
6
7
8
9
10
11
12
13
14
15
综上,通常状况,咱们一共会用到如下几种分支: staging、master、preview、release、dev、feature、bugfix、hotfix 。
# 分支的生命周期
示意图
# master 分支
默认存在,master 分支上保持最新的、稳定的代码。 从如下分支合并(merged from): dev、bugfix、hotfix
# preview 分支
从如下分支合并(merged from): master 合入如下分支: 一旦拉出,再也不合入其它分支 说明: preview 分支用于代码部署到生产环境前的预发布,用于正式上线前的最后一次测试。master 分支的代码部署到生产环境前,先用 merge (发 merge request 或用 git merge 命令,下同)把代码合入 preview 分支。
# release 分支
从如下分支合并(merged from): master 合入如下分支: 一旦拉出,再也不合入其它分支 说明: preview 分支的代码在预生产环境测试经过后,master 分支上、合入 preview 分支的结点,往 release 分支 merge 一次。
# staging 分支
从如下分支合并(merged from): feature 合入如下分支: 一旦拉出,再也不合入其它分支 说明: staging 分支的代码给 RD 测试功能用。RD 在 feature 开发完子功能后,把代码提交到 feature 分支,再把 feature 分支合到 staging 分支。最后在 xbox 上部署staging 环境,进行测试。
# dev 分支
派生自如下分支(forked from): master 合入如下分支: master 说明: dev 分支用于多人开发同一个功能时提交代码。它的存在时间跟新功能开发的时间相同。新功能开始开发时,它从 master 分支 fork 出来;新功能开发结束时,它被合入 master 分支,而后删除。
# feature 分支
派生自如下分支(forked from): dev 合入如下分支: staging、dev 说明: feature 分支用于 RD 我的提交代码。开发新功能时,每一个 RD 从 dev 分支 fork 出本身的 feature 分支,不一样 RD 在远程代码仓库不共享 feature 分支。当代码可测试时,先提交到 feature 分支,再 merge 到 staging 分支、发布、测试。测试通过后,merge 到 dev 分支。若是另一个 RD 须要依赖你的代码,他须要先将本身 feature 分支 rebase(用 git rebase 命令)到最新的 dev 分支(包含你的代码),而后进行开发。
# bugfix 分支
派生自如下分支(forked from): master 合入如下分支: staging、master 说明: bugfix 分支用于修复常规、不紧急的 bug。RD 开始修复 bug 时,从 master 分支 fork 出 bugfix 分支。提交修复代码后,把 bugfix 分支 merge 到 staging,在staging 环境发布、测试。测试经过后,再把 bugfix 分支 merge 到 master,而后删除。
# hotfix 分支
派生自(forked from): release 合入如下分支: staging、master、preview、release 说明: hotfix 分支用于修复生产环境的、紧急的 bug。RD 开始修复紧急 bug 时,从 release 分支 fork 出 hotfix 分支。提交修复代码后,把 hotfix 分支 merge 到 staging,在 staging 环境发布、测试。在 staging 测试经过后,再把 hotfix 分支 merge 到 preview,在 preview 环境进行测试。测试也经过后,再 merge 到 master、release 分支。
# 典型场景举例
下面举例一些常见场景,以及分支的操做步骤。
# 开发新的功能
- 某 RD 先从 master 分支 fork 出 dev 分支,命名为 dev_xxx 。
- 参与开发这个功能的 RD 基于 dev_xxx 分支 fork 出 feature_xxx_RDA,feature_xxx_RDB 等分支。
- 各 RD 在本身的 feature 分支开发子功能。
- RD A 在本身的分支 feature_xxx_RDA 上提交了几个工具类,这些类会给其余 RD 用。他把 feature_xxx_RDA push(用 git push 命令)到远程仓库,再 merge 到 staging,在 staging 环境发布、测试。若是测试发现问题,他再提交一个commit 到 feature_xxx_RDA 分支,而后 merge 到 staging,再发布、测试。测试经过后,他把 feature_xxx_RDA merge 到 dev_xxx 分>支,而后继续开发其它功能。
- RD B 的工做依赖 RD A 开发的工具类。他把 feature_xxx_RDB rebase 到 最新的 dev_xxx 分支,而后进行开发。
- 全部 RD 开发完后,某 RD 再把 dev_xxx 分支 merge 到 master 分支,而后删除 dev_xxx 分支。 某 RD 再把 master 分支 merge 到 preview 分支。
- 在 preview 测试经过后,再把 master 分支 merge 到 release 分支,而后发布到生产环境。
# 修复常规 bug
- 某 RD 领到一个 bug。开始修复时,他从 master 分支 fork 出 bugfix 分支,命名为 bugfix_xxx 。
- RD 在 bugfix_xxx 分支上提交修复代码,本身测试经过后,merge 到 staging,而且在 staging 环境发布、测试。若是测试发现问题,他再提交一个 commit 到 bugfix_xxx 分支,而后再 merge 到 staging,再发布、测试。直到测试彻底经过,他把 bugfix_xxx merge 到 master 分支,而后删除 bugfix_xxx 分支。
- 由于是常规 bug,他不须要立刻把修复的代码部署到生产环境。等待下一次发布周期便可。
# 修复线上紧急 bug
紧急 bug 是指若是不立刻修复,会形成重大损失的 bug。操作步骤如下
- 某 RD 领到一个紧急 bug。开始修复时,他从 release 分支 fork 出 hotfix 分支,命名为 hotfix_xxx。
- RD 在 hotfix_xxx 分支进行修复。提交代码后,他把 hotfix_xxx merge 到 staging,而且在 staging 环境发布、测试。若是测试发现问题,他再提交一个 commit 到 hotfix_xxx 分支,而后再 merge 到 staging,再发布、测试。直到测试彻底经过,他把 hotfix_xxx merge 到 preview 分支,在 preview 环境测试。若是测试发现问题,继续在 hotfix_xxx 分支提交修复代码,再 merge 到 staging 进行测试。
- preview 环境测试经过后,RD 把 hotfix_xxx merge 到 release 分支。上线,在生产环境观察 bug 是否修复。
- 若是生产环境还有问题,继续在 hotfix_xxx 修复,而后在 staging、preview 测试,测试经过再从新上线。这种状况应该尽量避免,保证一次上线修复成功。
- 生产环境验证没问题后,RD 把 hotfix_xxx merge 到 master,而后删除hot_xxx 分支。
建议:请勿在周五发布任何正式环境分支,以避免出现问题。
# 分支命名的建议
master、release、staging、preview 分支以它类型名字命名。
推荐的命名方式
- 对 dev 分支,建议以 dev_xxx_时间戳,其中,xxx 表示功能的英文简单描述,多个分词间用下划线分隔,时间戳用 yyyyMMdd 格式。如“保险礼品后台”功能的开发分支,可命名为 dev_ins_gift_20170329。
- 对 feature、bugfix、hotfix 分支,建议以 前缀_xxx_姓名 命名,其中前缀指 feature、bugfix、hotfix,xxx 表示功能的简单描述,姓名是负责开发功能的 RD 名字拼音。如修复链接数泄漏 bug 的分支,可命名为 bugfix_fix_conn_leak_zhangsan 。
# 分支命名反例
- 不包含任何前缀
- 只包含前缀、时间戳
- 只包含前缀、姓名
- 其它可读性低的命名
# 参考
PM、RD、FE、UE ......都是些啥? (opens new window)
- 01
- Python实现对字符串的加解密02-25
- 02
- Python3对大文件中指定字符进行排序再写入到新的文件10-24
- 03
- Ubuntu下配置adb环境连接Android设备进行调试08-17