😀前言
在这篇博文中,我将与大家分享关于Git分支管理的内容。Git作为一个分布式版本控制系统,在协同开发和版本控制中扮演着至关重要的角色。通过这篇文章,您将深入了解Git分支的原理、操作以及在实际开发中如何规范使用分支。希望这篇文章能对您的工作有所帮助,同时也非常期待您的宝贵意见,以帮助我不断改进。您的支持是我前进的动力,感谢大家的关注和阅读!
🏠个人主页:晨犀主页
🧑个人简介:大家好,我是晨犀,希望我的文章可以帮助到大家,您的满意是我的动力😉😉
💕欢迎大家:这里是CSDN,我总结知识的地方,欢迎来到我的博客,感谢大家的观看🥰
如果文章有什么需要改进的地方还请大佬不吝赐教 先在此感谢啦😊
文章目录
- Git分支管理
- **Git分支的原理**
- 分支规范
- 流程规范
- 正常开发流程
- 生产环境Bug修复流程
Git分支管理
Git分支的原理
分支在实际中有什么用呢?假设你准备开发一个新功能,但是需要两周才能完成,第一周你写了50%的代码,如果立刻提交,由于代码还没写完,不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交,又存在丢失每天进度的巨大风险。
现在有了分支,就不用怕了。你创建了一个属于你自己的分支,别人看不到,还继续在原来的分支上正常工作,而你在自己的分支上干活,想提交就提交,直到开发完毕后,再一次性合并到原来的分支上,这样,既安全,又不影响别人工作。
Git的分支是与众不同的,无论创建、切换和删除分支,Git在1秒钟之内就能完成!无论你的版本库是1个文件还是1万个文件。
在我们每次的提交,Git都把它们串成一条时间线,这条时间线就是一个分支。截止到目前,只有一条时间线,在Git里,这个分支叫主分支,即master分支。HEAD指针严格来说不是指向提交,而是指向master,master才是指向提交的。
一开始的时候,master分支是一条线,Git用master指向最新的提交,再用HEAD指向master,就能确定当前分支,以及当前分支的提交点:
每次提交,master
分支都会向前移动一步,这样,随着你不断提交,master
分支的线也越来越长:
当我们创建新的分支,例如dev
时,Git新建了一个指针叫dev
,指向master
相同的提交,再把HEAD
指向dev
,就表示当前分支在dev
上:
你看,Git创建一个分支很快,因为除了增加一个dev
指针,改改HEAD
的指向,工作区的文件都没有任何变化!
不过,从现在开始,对工作区的修改和提交就是针对dev
分支了,比如新提交一次后,dev
指针往前移动一步,而master
指针不变:
假如我们在dev
上的工作完成了,就可以把dev
合并到master
上。Git怎么合并呢?最简单的方法,就是直接把master
指向dev
的当前提交,就完成了合并:
所以Git合并分支也很快!就改改指针,工作区内容也不变!
合并完分支后,甚至可以删除dev
分支。删除dev
分支就是把dev
指针给删掉,删掉后,我们就剩下了一条master
分支:
分支规范
许多公司的开发团队都采用Git来做代码版本控制。如何有效地协同开发人员之间,以及开发、测试、上线各环节的工作,可能都有各自的流程与规范。
创建项目时,会针对不同环境创建三个常设分支:
- develop:开发环境的稳定分支,公共开发环境基于该分支构建。
- pre-release:测试环境的稳定分支,测试环境基于该分支构建。
- master:生产环境的稳定分支,生产环境基于该分支构建。仅用来发布新版本,除了从pre-release或生产环境Bug修复分支进行merge,不接受任何其它修改
平时开发工作中,会根据需要由开发人员创建两类临时分支:
- 功能(feature)分支:为了开发某个特定功能,从develop分支上面分出来的。开发完成后,要merge到develop分支。功能分支的命名,可以采用feature-*的形式命名(*为任务单号)
- Bug修复(fixbug)分支:为了修复某个bug,从常设分支上面分出来的。修复完成后,再merge到对应的分支。Bug修复分支的命名,可以采用fixbug-*的形式命名(*为bug单号)
流程规范
正常开发流程
- 从develop分支切出一个新分支,根据是功能还是bug,命名为feature-* 或 fixbug-*。
- 开发者完成开发,提交分支到远程仓库。
- 开发者发起merge请求(可在gitlab页面“New merge request”),将新分支请求merge到develop分支,并提醒code reviewer进行review
- code reviewer对代码review之后,若无问题,则接受merge请求,新分支merge到develop分支,同时可删除新建分支;若有问题,则不能进行merge,可close该请求,同时通知开发者在新分支上进行相应调整。调整完后提交代码重复review流程。
- 转测时,直接从当前develop分支merge到pre-release分支,重新构建测试环境完成转测。
- 测试完成后,从pre-release分支merge到master分支,基于master分支构建生产环境完成上线。并对master分支打tag,tag名可为v1.0.0_2019032115(即版本号_上线时间)
流程示意图如下所示
生产环境Bug修复流程
-
生产环境的Bug分两种情况:
- 紧急Bug:严重影响用户使用的为紧急Bug,需立即进行修复。如关键业务流程存在问题,影响用户正常的业务行为。
- 非紧急Bug或优化:非关键业务流程问题,仅影响用户使用体验,或出现频率较小等,为非紧急Bug,可规划到后续版本进行修复。
非紧急Bug修复参考“正常开发流程”。
紧急Bug修复,需要从master分支切出一个bug修复分支,完成之后需要同时merge到master分支与develop分支(如果需要测试介入验证,则可先merge到pre-release分支,验证通过后再merge到master分支上线)。merge时参考“正常开发流程”。流程示意图如下
1、创建分支
2、切换/检出分支
3、提交文件至分支
4、合并分支
5、推送分支文件到master
文章到这里就结束了,如果有什么疑问的地方请指出,诸大佬们一起来评论区一起讨论😁
希望能和诸大佬们一起努力,今后我们一起观看感谢您的阅读🍻
如果帮助到您不妨3连支持一下,创造不易您们的支持是我的动力🤞