Git的研发应用场景是怎样的
Git的研发应用场景是怎样的,很多新手对此不是很清楚,为了帮助大家解决这个难题,下面小编将为大家详细讲解,有这方面需求的人可以来学习下,希望你能有所收获。
我们提供的服务有:网站建设、做网站、微信公众号开发、网站优化、网站认证、夏县ssl等。为上千余家企事业单位解决了网站和推广的问题。提供周到的售前咨询和贴心的售后服务,是有科学管理、有技术的夏县网站制作公司
Git诞生于2002年,由Linux之父Linus Torvalds和他的团队开发并不断完善,它秉承了Linux的开源精神,为广大研发团队带来了非常棒的版本控制体验。下面立足Git的工作原理,深入探讨各种研发场景中工作流等问题。
Git工作模式
代码提交过程
一次修改被成功提交到远端仓库会历经四个阶段,1本地工作区->2缓存区->3版本库->4远端版本库,通过执行相应的Git命令,文件在这四个区域跳转,并呈现不同的状态:
1.已修改(modified):包括三种文件,新增文件,被修改的文件,被删除的文件
2.已暂存(staged):对已修改的文件执行git add或git rm操作,文件就变成已暂存状态,进入暂存区。暂存区实际上就是一个文件索引目录树,记录了所有文件名、文件状态信息,它已索引的方式建立了文件名和文件内容(在对象库.git/objects中保存)的对应关系。
3.已提交(committed):对已暂存的文件执行git commit操作,文件就变成已提交状态,进入本地版本仓库。
4.已上传:对已提交的文件执行git push操作,文件就变成已上传状态,进入远端版本仓库。
Git如何记录每次提交
我们思考一下,版本控制系统应该如何记录每次提交呢?正常的思维肯定是记录“差异”(delta),也就是前后两个版本中文件内容的不同,确实大多数版本控制系统是这么做的,比如我们所熟悉的CVS,SVN。但是,Git却不这样!每次提交更新时,Git会对全部文件作一个快照(snapshot),并保存指向这次快照的索引。
这种保存方式带来很多好处,切换版本时,直接引用指向目标版本的索引即可,不需要像差异存储那样,需要版本之间的merge,速度会快很多,更重要的是,为后文所讲到的轻量级分支切换提供了前提条件。
Git分支
Git新建分支的本质就是创建一个指向最后一次提交的可变指针,所以,Git分支的创建不是复制版本库的内容,仅仅是新建了一个指针,它以40个字符长度SHA-1字串形式保存在文件中,这难以想象的轻量级就是源于“快照”保存的版本设计理念。
Git工作流
什么是Git工作流?你可以理解为代码管理的分支策略。这里从典型的GitFlow工作流出发,配合我正在使用的代码托管平台(华为软件开发云),给大家详细讲解工作流是如何服务于项目流程管理和团队协同开发。
Ømaster:主线分支,版本有较强稳定性,供生产环境部署使用,这个分支只能从其它分支合并,不能在这个分支上直接提交修改。
新建分支:
在开发云界面输入新分支名,并选择从哪个分支检出即可。
Ødevelop:主开发分支,用来集成测试最新合入的开发成果,包含要发布到下一个Release的代码。
Øfeature:特性分支,每个特性一个分支,用于开发人员提交代码并进行自测。一旦开发完成,我们合并回Develop分支进入下一个Release。
Øhotfix:补丁分支,生产环境发现新Bug时创建的临时分支,问题验证后,合并到Master和Develop分支,所以Hotfix的改动会进入下一个Release
Ørelease:发布分支,发布新版本时,基于Develop分支创建,发布完成后,合并到master和develop分支。
各个分支之间的关系可以从开发云的“仓库网络”中查看:
优点:项目管理流程明确
缺点:相对复杂,需要同时维护两个长期分支,不适合网站项目。
分支合并
无论哪种工作流都会涉及到分支合并(把一个分支中的修改整合到当前分支),主要有两种方法:三方合并(merge)和衍合(rebase)。我们通过对同一种场景进行不同操作体会两种合并方法的区别。
场景:master分支新增了C4节点,hotfix分支新增了C3节点,现将hotfix分支合并到master分支:
1.三方包括hotfix新增节点C3,master新增节点C4,以及两者的共同祖先节点C2。这种合并操作简单,但新增合并节点C5,形成了环形,版本记录可读性差。
a)PC端命令操作方式:
#git checkout master
#git merge hotfix
b)开发云平台页面操作:
第一步:
第二步:
2.衍合先将master分支新增节点C4以补丁形式保存在.git/rebase目录中,然后同步hotfix分支最新代码,再应用补丁C4’。
#git checkout master
#git rebase hotfix
冲突解决
类型一:两个合并分支修改了同一行代码
解决方法:
1.分析哪种修改方法正确,手动合并;
2.提交修改。
类型二:文件被重命名为不同的名字
解决方法:
1.确认哪个名字是正确的,删除错误的;
2.提交修改。
看完上述内容是否对您有帮助呢?如果还想对相关知识有进一步的了解或阅读更多相关文章,请关注创新互联行业资讯频道,感谢您对创新互联的支持。
文章标题:Git的研发应用场景是怎样的
转载来源:http://myzitong.com/article/pccosc.html