分类目录

登录

统计信息

  • 日志总数:238篇
  • 评论总数:386条
  • 分类总数:3个
  • 标签总数:537个
  • 友情链接:11个
  • 网站运行:3242天

西安市公共自行车 微信小程序 入口扫描,扫我进入~

个人信息

·网名:青年白
·生日:1991年9月17日
·博客: http://www.baikeyang.com
·邮箱:baikeyang@vip.qq.com
·籍贯: 陝西省汉中市
·工作: 杭州鸿泉数字设备有限公司
·职位:Java软件开发工程师
·地址:西安市高新区丈八一路绿地SOHO
·   同盟A座606室
·时间:2015.07─至今
·工作: 西安易一电子科技有限公司
·职位:Java中级软件开发工程师
·地址:西安市高新区科技二路软件园
·   西岳阁403室
·时间:2014.05─2015.06
·工作:陕西齐力集团
·职位:初级软件开发工程师
·地址:西安市建工路19号新城科技产业园
·   华企大厦7层
·时间:2013.05─2014.04
现在位置:    首页 > 技术乱弹 > 正文
Git学习(第七天)
技术乱弹 暂无评论
我们在合并分支时,Git会用到”Fast forward“模式,在这种模式下删除分支后会丢掉分支信息。
如果我们要强制禁用”Fast forward“模式,Git就会在merge时生存一个新的commit,这样从分支历史上就可以看出分支信息。
那么,如何强制禁用”Fast forward“模式呢?在merge时 加上参数 –no-ff 即可。
创建并切换一个分支dev:

修改readme.txt文件并提交:

提交完成后切换至master:

现在开始合并dev分支到master,在使用merge时使用–no-ff禁用”Fast forward“:

因为本次禁用了”Fast forward“合并会创建一个新的commit,所以在后面加上了-m参数,把commit描述写进去。合并后可以使用git log查看分支历史:

可以从上面的操作历史中看到,不使用”Fast forward”模式,merge后就像这样:
分支策略:
通常在实际的开发中,我们应该按照几个基本原则进行分支管理:
首先,master分⽀应该是非常稳定的,也就是仅用来发布新版本,平时不能在上⾯干活;
那在哪干活呢?干活都在dev分支上,也就是说,dev分⽀是不稳定的,到某个时候,比如1.0版本发布时,再把dev分支合并到master上,在master分⽀发布1.0版本;
你和你的⼩伙伴们每个人都在dev分支上干活,每个人都有自己的分支,时不时地往dev分支上合并就可以了。
所以,团队合作的分⽀支看起来就像这样:
小结
Git分支十分强大,在团队开发中应该充分应用。
合并分支时,加上–no-ff参数就可以用普模式合并,合并后的历史有分支,能看出来曾经做过合并,而fast forward合并就看不出来曾经做过合并。
BUG分支:
软件开发中,产生BUG几乎是我们每天无法避免的一件事。当然,既然有了BUG那就需要修复。比如现有一个BUG需要马上进行修复处理。这个时候,就可以体现出Git中强大的分支管理了。我们可以通过一个临时分支来修复BUG,修复后合并分支,然后将临时分支删除。
但接到一个修复的BUG任务,很自然地想到创建一个分支issue-105来修复他,但是我们当前正在dev上进行着开发工作,这部分代码还没有提交:

由于我的功能开发到一半,预计开发完成至少还需要1天,很显然这个未完成的代码是不能提交的。但是目前必须需要在最短的时间内修复这个BUG,怎么办?
强大的Git为我们提供了一个stash功能,可以把当前的工作现场”储藏“起来,等以后恢复现场继续工作:

现在用git status查看工作区:

目前工作区是干净的(除还没有被Git管理的文件),因此可以放心的创建分支来修复Bug。首先得确认修复BUG是在那个分支上。假设我们需要在master上修复该BUG,就在master上创建临时的分支:

修改文件然后提交:

提交完成后,切换到master分支,合并issue-105分支,合并完成后删除issue-105分支:

好的。BUG105我们已经修复并提交了master了。现在我们需要返回dev继续干刚才没有完成的活。

工作区我们刚刚在dev修改的文件,哪去了?不要着急。用git stash list 命令查看:

dev的工作现场还在,Git只是把stash内容存放在某个地方了,但是需要恢复一下,有两个方法:
1、 使用git stash apply 恢复,但是在恢复后,stash内容并没有删除,需要使用git stash drop 来删除;

2、使用git stash pop,恢复的同时把stash内容也删除了:

再用git stash list查看,就看不到任何的stash内容:
可以多次stash,恢复的时候先用git stash list查看队列,然后恢复时指定stash序列;stash的队列是按照的时间的先后顺序倒叙排列的(即时间最新的在前,stash@{0});存在多个stash在不指明恢复序列,默认为队列第一个。

修改BUG时,我们会通过创建新的BUG分支进行修复,然后合并,最后删除;当手头工作没有完成时,先把工作现场git stash一下,然后去修复bug,修复完成后,再git stash pop,重新回到工作现场。

本文版权归青年博客所有,转载引用请完整注明以下信息:
本文作者:BaiKeyang
本文地址:Git学习(第七天) | 青年博客

发表评论

留言无头像?