1.前言
本文是笔者依据当前工作条件编写,目前阶段看具有普适性。但随着项目规模增长以及技术的迭代更新,往后看本文具有一定的时代局限性。所以各位读者按需取用,可在本文的基础上对其中内容加以改进,以便更好的去适应于自身所在公司项目分支管理。
2.基本概念介绍
2.1 开发环境(DEV)
开发环境是程序员们在开发过程中进行对代码进行测试的服务器,为了自身测试方便,配置简洁、变更频繁。
2.2 测试环境(TEST)
测试环境是测试人员对代码进行测试的服务器,配置较为正式,主要是用来对代码做白盒测试。
2.3 验收环境(UAT)
UAT(User Acceptance Test),用户接受度测试(即验收测试),是用来作为客户体验的服务器,配置与生产环境相同,但不连接生产数据库。
2.4 生产环境(PRO)
生产环境是指正式提供对外服务的服务器,一般会关掉错误报告,打开错误日志。可以理解为包含所有的功能的环境,任何项目所使用的环境都以这个为基础,然后根据客户的个性化需求来做调整或者修改。
3.简介
Git是一个开源的分布式版本控制系统,可以方便相关管理员对项目材料进行版本管理。
4.基本命令
命令 | 语义 | 示例 |
---|---|---|
git pull [项目集合] [分支] | 拉取指定代码集中指定分支的代码 | git pull origin develop |
git add xxx(文件名) | 向工作缓存区添加待提交文件 | git add * |
git commit -m ‘本次提交内容注释’ | 将工作缓存区的内容提交至本地代码仓库 | git commit -m ‘Issue:3359 修复后台界面查询效率过慢问题’ |
git push -u [项目集合] [分支] | 将本地仓库代码提交至远端仓库 | git push -u origin develop |
git stash save ‘message’ | 暂存本地分支修改 | git stash save -u ‘限制两个用户同时修改数据问题’ |
git merge 分支名称 | 将指定分支的代码合并到当前分支 | git merage feature_20200407_IssueNum |
git stash list | 查看当前有哪些暂存内容 | |
git stash pop stash@{$num} | 将指定暂存内容应用到当前分支,并删除该暂存内容 | git stash pop stash@{0} |
注:在使用命令提交代码至远端仓库时,禁止使用git push -f origin develop
强制提交。
5.常用分支介绍
按分支存在周期划分为两种:长期分支 、短期分支。
5.1 长期分支
5.1.1 主分支(master branch)
- 该分支只有一个,用于存储正式发布的历史代码,向用户交付正式使用版本。
- 该分支是所有开发活动的核心分支,所有的开发活动产生的输出物最终都会反映到主分支的代码中。
- 该分支始终和生产环境保持一致。
- 该分支在每次commit之后需要打上Tag。
- 命名规则:
- master(无需修改)
除分支管理人员外,禁止任何人擅自将代码提交至master或将分支合并至master
除分支管理人员外,禁止任何人擅自将代码提交至master或将分支合并至master
除分支管理人员外,禁止任何人擅自将代码提交至master或将分支合并至master
5.1.2 验收分支(uat branch)
- 该分支只有一个,用于项目第二轮集成测试(用户验收测试)
- 该分支始终和UAT环境保持一致
- 当该分支通过用户验收测试后,将代码合并到master branch,准备进行发版
- 命名规则:
- uat(无需修改)
5.1.3 开发分支(develop branch)
- 该分支只存在一个,用于项目第一轮集成测试(测试人员测试)
- 该分支始终和开发环境保持一致
- 该分支不允许直接合并至master分支,仅做功能分支(feature branch)代码合并及自动构建测试包使用。
- 命名规则:
- develop(无需修改)
5.2 短期分支
5.2.1 功能分支(feature branch)
- 该分支在每个迭代中可能并行存在多个,诞生于develop branch或uat branch。
- 该分支用于独立开发功能点,保证各功能点互不影响。
- 该分支在合并代码后删除。
- 命名规则:
- feature-开发功能名称
- ex:feature-用户登陆
5.2.2 补丁分支(hotfix branch)
- 该分支是最不希望出现的分支,用于线上问题紧急修复。
- 该分支诞生于master branch。
- 在问题修复后,该分支合并至master branch、uat branch、develop branch后删除。
- 命名规则:
- hotfix–bug描述
- ex:hotfix–双用户并发操作异常
6.分支使用规范
6.1 代码合并问题
- 合并代码至公共分支时,请使用merge,勿使用rebase。
- 将公共分支代码合并至个人开发分支时,使用rebase、merge均可,但推荐使用rebase,这样可以将自己的修改放在主线修改的头上。
6.2 冲突解决
- 当merge或rebase过程中产生冲突,请优先使用他人版本覆盖,请勿强制提交本地修改至分支,导致他人功能异常。
6.3 项目分支图解(重要)
-
当需要进行新功能或新需求开发时,依据develop branch创建feature branch。如图:
-
当feature branch完成开发并自测后,将代码merge至develop branch,然后删除feature branch(用完即删),develop branch将会自动打包部署至开发环境供测试人员进行测试。如图:
-
当测试人员在develop branch完成测试后,分支管理员将develop branch代码合并至uat branch,进行用户验收测试(uat 测试)。如图:
-
用户验收测试通过后,将代码合并至master branch进行构建发布并打上Tag标签。如图:
以上为项目在集成测试、验收测试中均一次性通过的流程图解。但在日常开发中,必然会因思考不周全或对需求理解不透彻而出现bug或返工,那么这个时候,要怎么去管理分支呢?接下来我们对项目分支异常流进行一个图解。
- 在集成测试时出现bug。
- 这个时候需要以当前develop branch为基准,创建新的feature branch进行bug修复。
- 完成修复并自测通过,将代码集成至develop branch。
- 测试人员测试通过,将代码集成至uat branch。
- 用户验收测试通过,将代码集成至master branch打包发布,并打上Tag标签。
- 整个过程如图所示:
- 在用户验收测试时出现bug。
- 这个时候需要以当前uat branch为基准,创建新的feature branch进行bug修复。
- 完成修复并自测通过,将代码集成至uat branch。
- 交由测试人员进行测试。
- 测试人员通过,进行用户验收测试。
- 用户验收测试通过,将代码分别集成至develop branch、master branch,并在master branch打包发布,并打上Tag标签。
- 整个过程如图所示:
- 在线上运行时,突然爆出一个bug。
- 以master branch为基准,拉出一个hotfix branch,对bug进行修复。
- 完成自测并通过测试人员测试,将代码分别集成至develop branch、uat branch、master branch后删除hotfix branch,并对master branch打Tag,打包发布。
- 如图:
6.4 多人协作问题
由于之前并未对多人协作以及分支管理作出明确规范,故现存在多人协作修改同一模块的不同bug时分支混乱的情况,所以现需要对分支在多人协作情况下的使用作出明确规范,以提高资源利用率,避免在此类无意义的问题上浪费时间。
6.4.1 多人协作修改同一个模块的不同bug(非线上bug)
- 分支创建及使用
- 以develop branch为基准,由当前该问题负责人拉取一个feature branch(请注意命名规范)
- 相关人员使用同一分支进行修复
- 分支代码提交
- 若修改功能耦合度较高,那么提交前请在群中知会相关同事,错时提交。
- 若提交时产生冲突,请勿强行提交覆盖分支代码,优先使用他人代码覆盖自己代码。
- 所有人提交完成后,当前问题负责人通知在该分支开发的所有人,进行自测,确认自己所负责代码块是否正常运行,需检查以下几点:
- 代码是否可以正常编译
- 代码是否可以正常启动
- 流程是否可以跑通
- 数据是否正确落库
- 落库数据是否正确
-
自测完成后,当前问题负责人将代码合并至develop branch,并删除feature branch
-
提测
流程如图所示:
6.4.2 多人协作修改同一个模块的不同bug(线上bug)
- 分支创建及使用
- 以master branch为基准,由当前该问题负责人拉取一个feature branch(请注意命名规范)
- 相关人员使用同一分支进行修复
- 分支代码提交
- 若修改功能耦合度较高,那么提交前请在群中知会相关同事,错时提交。
- 若提交时产生冲突,请勿强行提交覆盖分支代码,优先使用他人代码覆盖自己代码。
- 所有人提交完成后,当前问题负责人通知在该分支开发的所有人,进行自测,确认自己所负责代码块是否正常运行,需检查以下几点:
- 代码是否可以正常编译
- 代码是否可以正常启动
- 流程是否可以跑通
- 数据是否正确落库
- 落库数据是否正确
- 自测完成后,将当前分支打包部署交由测试人员测试
- 测试人员测试通过后,由当前问题负责人分别合并至develop branch、uat branch、master branch,并在master branch打上Tag,由master branch打包发布。
过程如图所示:
6.4.3 多人协作修改同一流程不同模块的业务
这种情况下开发人员拉取分支独立开发,在开发完成后与流程上下方进行一个联调,以确保上下游数据产生以及处理通畅无误。具体流程请参考6.3 项目分支图解。
PS:若大家有什么想法或建议,可在评论区向我留言,我会积极向各位大佬学习并改进!!!感谢!!!