git–基础–04–分支管理规范
1、 git-flow模型
- 分支管理采用git-flow 模式,预设两个主分支在仓库中
- master分支
- develop分支
- 开发人员不可以直接操作这两个分支,在开发完成的功能分支提交到远程仓库后,需要提出merge request,由技术管理人员合并至develop分支。
2、master和develop分支
- 称作为长期分支。
- 存活在项目的整个生命周期中。
2.1、发布主分支master
- 每个代码库只有一个
- 只用于发布生产的正式版本,同时要对应生成一个tag。
- master分支的所有提交都应是提供给用户的正式版本。
- 需确保master分支的任何内容都是可部署的
- 只允许对master进行其他分支的合并和创建标记操作,不能单独在master分支上进行提交。
- master分支应该只授权给项目代码的管理者,不允许其余人员操作。
2.2、开发主分支develop
- 是进行开发的基础分支,其他分支是基于develop分支切分出来的
- 其他分支开发完成后,会合并在develop分支中,等待被整合到master分支中。
3、其他分支
- 也叫临时分支,只是临时存在的,它们是根据需要来创建的,例如
- 针对功能开发的分支
- 针对版本发布的分支
- 其他分支开发完成后,会合并在develop分支中,自己会被删除掉。
3.1、功能分支feature
- 是功能分支,开发某个功能点而创建。
- 完成功能点的开发后,feature分支的最新内容会被部署至 SIT(测试环境) 进行功能测试验收。
- 功能点测试完成后再合并入 develop分支,并删除 feature分支。
3.1.1、分支命名格式1
- feature目录下
- 开发人员的名字拼音–功能的名字拼音–版本号
- 例如:
- zhoufei-goutong-v1,表示 开发人员是周飞,沟通功能,版本是v1
3.1.2、分支命名格式2
- feature-[任务号码]
- 例如
- feature-10980,10980对应任务管理平台中的任务号码
3.2、预发布分支release
- 发布正式版本之前(即合并到master分支之前),基于develop分支切出来的
- 作为预发布版本以此进行测试的分支。
- 一个release分支对应一个版本发布计划,包含一个或多个的用户故事、不定量的功能点、漏洞修复等。
- 完成发布计划的所有开发后,将release分支的内容 会部署到 UAT(仿真环境) 进行测试验收。
- 最后确认发布后,需要将release分支合并至master分支和develop分支,并删除该release分支,然后基于最新的master分支创建一个新的版本标记,基于tag进行生产环境部署。
3.2.1、分支命名格式
- release目录下
- release-[版本号]
- 例如release-0.1.0。
3.3、修补Bug分支bugfix
- 开发过程中,发现了develop代码的漏洞,对于发现的漏洞进行修补的分支
- 基于develop分支切分出来,与feature的开发过程比较类似。
- 完成漏洞修补的开发后,bugfix分支的最新内容会被部署至 SIT(测试环境),进行功能测试验收。最后将其合并入develop分支,并删除bugfix分支。
3.3.1、分支命名格式1
- bugfix目录下
- 开发人员的名字拼音–功能的名字拼音
- 例如:
- zhoufei-goutong,表示 开发人员是周飞,修补沟通功能
3.3.2、分支命名格式2
- bugfix目录下
- bugfix-[任务号码]
- 例如bugfix-10980,10980对应任务管理系统中的bug任务号码。
3.4、热修复分支hotfix
- 软件正式发布以后,难免会出现Bug,这时就需要创建一个hotfix分支 ,进行Bug热修复。
- 与bugfix不同的地方在于,hotfix是基于master分支进行切分的,完成会合并入master分支,再合并到develop分支。
- 漏洞修复后需要为hotfix分支制作一个新的修订号版本标记。最后,根据实际情况可选的合并入master分支,再合并到develop分支,并删除 hotfix分支。
3.4.1、分支命名格式1
- hotfix目录下
- hotfix-[新版本号码]
- 例如hotfix-0.1.1。
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。