首页
留言
关于
友链
更多
足迹
实验室
地图组件
Search
1
SpringMVC+Spring+MyBatis整合完整版Web实例(附数据)
2,628 阅读
2
关于在Flutter实现Google地图的方法
1,042 阅读
3
SqlServer分组排序后取第一条记录
709 阅读
4
Maven仓库报错:Could not transfer artifact org.springframework.boot:spring-boot-maven-plugin:pom···
623 阅读
5
druid报异常 “sql injection violation, part alway true condition not allow”的解决方案
531 阅读
发现
技术
生活
户外
登录
Search
标签搜索
Git
JavaScript
Oracle
Git学习
Java
Flutter
MySQL
SQL Server
Spring Boot
对称加密算法
IntelliJ IDEA
Google地图
Maven
ES6
秦岭户外
Flutter 2.0
linux
Tomcat
Redis
Spring
Bai Keyang
累计撰写
269
篇文章
累计收到
275
条评论
首页
栏目
发现
技术
生活
户外
页面
留言
关于
友链
足迹
搜索到
1
篇与
Bug分支
的结果
2018-11-25
Git学习(第七天)
我们在合并分支时,Git会用到”Fast forward“模式,在这种模式下删除分支后会丢掉分支信息。如果我们要强制禁用”Fast forward“模式,Git就会在merge时生存一个新的commit,这样从分支历史上就可以看出分支信息。那么,如何强制禁用”Fast forward“模式呢?在merge时 加上参数 --no-ff 即可。创建并切换一个分支dev:$ git checkout -b dev Switched to a new branch 'dev' 修改readme.txt文件并提交:$ git add readme.txt $ git commit -m '修改readme' [dev c835981] 修改readme 1 file changed, 1 insertion(+) 提交完成后切换至master:$ git checkout master Switched to branch 'master' Your branch is ahead of 'GitGo/master' by 7 commits. (use "git push" to publish your local commits) 现在开始合并dev分支到master,在使用merge时使用--no-ff禁用”Fast forward“:$ git merge --no-ff -m '禁用fast forward方式合并文件' dev Merge made by the 'recursive' strategy. readme.txt | 1 + 1 file changed, 1 insertion(+) 因为本次禁用了”Fast forward“合并会创建一个新的commit,所以在后面加上了-m参数,把commit描述写进去。合并后可以使用git log查看分支历史:$ git log --graph --pretty=oneline --abbrev-commit * 068ed5b (HEAD -> master) 禁用fast forward方式合并文件 |\ | * c835981 (dev) 修改readme |/ * da26543 修改文件内容 |\ | * cfc178e 修改Git为git * | 898bd79 修改文字为繁体字,修改标点符号为英文 |/ * e235cf1 一个新的版本 * 081fd0d 修改后的文件 |\ | * 3b0631c 分支冲突解决学习1 * | 607fe21 修改的今天修改的内容【学习分支冲突解决方法】 |/ * cde8ce3 (GitGo/master) 添加测试文件 * 742b3d0 新增许可证描述文件;修改项目说明文件; * 53b0c21 添加了一段文字 Add Time:2017-01-05 * 4b7b169 修改描述文档 * 068eefe wrote a readme file 可以从上面的操作历史中看到,不使用"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上进行着开发工作,这部分代码还没有提交:$ git status On branch dev Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: LICENSE.txt 由于我的功能开发到一半,预计开发完成至少还需要1天,很显然这个未完成的代码是不能提交的。但是目前必须需要在最短的时间内修复这个BUG,怎么办?强大的Git为我们提供了一个stash功能,可以把当前的工作现场”储藏“起来,等以后恢复现场继续工作:$ git stash Saved working directory and index state WIP on dev: c835981 修改readme 现在用git status查看工作区:$ git status On branch dev nothing to commit, working tree clean目前工作区是干净的(除还没有被Git管理的文件),因此可以放心的创建分支来修复Bug。首先得确认修复BUG是在那个分支上。假设我们需要在master上修复该BUG,就在master上创建临时的分支:$ git checkout master Switched to branch 'master' Your branch is ahead of 'GitGo/master' by 11 commits. (use "git push" to publish your local commits) $ git checkout -b issue-105 Switched to a new branch 'issue-105' 修改文件然后提交:$ git add test.txt $ git commit -m '修改BUG' [issue-105 05372b9] 修改BUG 1 file changed, 1 insertion(+), 1 deletion(-) 提交完成后,切换到master分支,合并issue-105分支,合并完成后删除issue-105分支:$ git checkout master Switched to branch 'master' Your branch is ahead of 'GitGo/master' by 11 commits. (use "git push" to publish your local commits) $ git merge --no-ff -m '修复BUG105' issue-105 Merge made by the 'recursive' strategy. test.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) $ git branch -d issue-105 Deleted branch issue-105 (was 05372b9). 好的。BUG105我们已经修复并提交了master了。现在我们需要返回dev继续干刚才没有完成的活。$ git checkout dev Switched to branch 'dev' $ git status On branch dev nothing to commit, working tree clean 工作区我们刚刚在dev修改的文件,哪去了?不要着急。用git stash list 命令查看:$ git stash list stash@{0}: WIP on dev: c835981 修改readmedev的工作现场还在,Git只是把stash内容存放在某个地方了,但是需要恢复一下,有两个方法:1、 使用git stash apply 恢复,但是在恢复后,stash内容并没有删除,需要使用git stash drop 来删除;$ git stash apply On branch dev Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: LICENSE.txt no changes added to commit (use "git add" and/or "git commit -a") $ git stash drop Dropped refs/stash@{0} (190f697d730a4a7816b3049acf7cf33d6d162162) 2、使用git stash pop,恢复的同时把stash内容也删除了:$ git stash pop On branch dev Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: LICENSE.txt no changes added to commit (use "git add" and/or "git commit -a") Dropped refs/stash@{0} (62947f8efd82d5b72410cdabd47eaaffa4d53dca) 再用git stash list查看,就看不到任何的stash内容:$ git stash list可以多次stash,恢复的时候先用git stash list查看队列,然后恢复时指定stash序列;stash的队列是按照的时间的先后顺序倒叙排列的(即时间最新的在前,stash@{0});存在多个stash在不指明恢复序列,默认为队列第一个。$ git stash list stash@{0}: WIP on dev: c835981 修改readme stash@{1}: WIP on dev: c835981 修改readme stash@{2}: WIP on dev: c835981 修改readme $ git stash apply stash@{1} On branch dev Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: LICENSE.txt no changes added to commit (use "git add" and/or "git commit -a") $ git stash drop stash@{1} Dropped refs/stash@{1} (159798b0499e0acf7cf33d6d162162a5fff64f0d) 修改BUG时,我们会通过创建新的BUG分支进行修复,然后合并,最后删除;当手头工作没有完成时,先把工作现场git stash一下,然后去修复bug,修复完成后,再git stash pop,重新回到工作现场。
2018年11月25日
246 阅读
0 评论
0 点赞