首页
留言
关于
友链
更多
足迹
实验室
地图组件
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
条评论
首页
栏目
发现
技术
生活
户外
页面
留言
关于
友链
足迹
搜索到
2
篇与
Git分支管理
的结果
2018-11-13
Git学习(第六天)
在项目中,通常会发生多个人对一个文件进行修改,这样在合并分支的时候就很难避免不发生冲突。一旦在我们合并的时候出现冲突,这个时候我们该怎么解决呢?下面以一个例子来演示冲突如何解决:准备一个新的分支:featrue1,继续在新的分支开发:$ git checkout -b feature1 Switched to a new branch 'feature1' 查看当前的工作区指向的是哪个分支:$ git branch * feature1 master 接下来,修改feature1分支中的readme.txt:feature1分支中的readme.txt原来的内容:”Git学习:解决冲突。"(如上图)修改为:”git学习:解决冲突。"(如下图)修改完成后在feature1分支上提交:$ git add readme.txt $ git commit -m '修改Git为git' [feature1 cfc178e] 修改Git为git 1 file changed, 1 insertion(+), 1 deletion(-) 切换到master分支上:$ git checkout master Switched to branch 'master' Your branch is ahead of 'GitGo/master' by 1 commits. (use "git push" to publish your local commits) Git还会自动提示我们当前master分支比远程的master分支要超前1个提交。在master分支上把readme.txt文件的内容进行修改:master分支中的readme.txt原来的内容:”Git学习:解决冲突。"(如上图)修改为:”Git学習:解决冲突."(如下图)在master分支上提交readme.txt文件:$ git add readme.txt $ git commit -m '修改文字为繁体字,修改标点符号为英文' [master 898bd79] 修改文字为繁体字,修改标点符号为英文 1 file changed, 1 insertion(+), 1 deletion(-) 好了,现在master分支和feature1分支各自都分别有新的提交了:这种情况下,Git无法执行“快速合并”,只能试图把各自的修改合并起来,但这种合并就可能会有冲突,我们试试看:$ git merge feature1 Auto-merging readme.txt CONFLICT (content): Merge conflict in readme.txt Automatic merge failed; fix conflicts and then commit the result. 果然冲突了!Git告诉我们,readme.txt文件存在冲突,必须手动解决冲突后再提交。git status也可以告诉我们冲突的文件:$ git status On branch master Your branch is ahead of 'GitGo/master' by 5 commits. (use "git push" to publish your local commits) You have unmerged paths. (fix conflicts and run "git commit") (use "git merge --abort" to abort the merge) Unmerged paths: (use "git add <file>..." to mark resolution) both modified: readme.txt no changes added to commit (use "git add" and/or "git commit -a") 现在直接查看readme.txt的内容:Git 用<<<<<<<,=======,>>>>>>> 标记出不同分支的内容,我们修改如下后保存:再提交:$ git add readme.txt $ git commit -m '修改文件内容' [master da26543] 修改文件内容 现在,master分支和feature1分支变成了下图所示:用带参数的git log也可以看到分支的合并情况:$ git log --graph --pretty=oneline --abbrev-commit * da26543 (HEAD -> master) 修改文件内容 |\ | * cfc178e (feature1) 修改Git为git * | 898bd79 修改文字为繁体字,修改标点符号为英文 |/ * e235cf1 一个新的版本 * cde8ce3 (GitGo/master) 添加测试文件 * 742b3d0 新增许可证描述文件;修改项目说明文件; * 53b0c21 添加了一段文字 Add Time:2017-01-05 * 4b7b169 修改描述文档 * 068eefe wrote a readme file 当我们合并分支解决完冲突之后,删除feature1分支:$ git branch -d feature1 Deleted branch feature1 (was cfc178e). OK,到这里为止,在进行分支合并中出现的冲突就算是解决完成了。总结:1、当Git无法自动合并分支时,就必须首先解决冲突。解决冲突后,再提交,合并完成。2、解决冲突就是把Git合并失败的文件手动编辑为我们希望的内容,再提交。3、用git log --graph命令可以看到分支合并图。
2018年11月13日
216 阅读
0 评论
0 点赞
2018-06-29
Git学习(第五天)
Git分支管理分支就是美国科幻大片里面的平行空间,当你正在电脑前努力学习Git的时候,另一个你正在另一个平行宇宙里努力学习SVN。两个平行空间互不干扰。但是在某个时间,两个空间合并了。然后你就学会的两个技能Git和SVN。分支在实际中有什么用呢?假设你准备开发一个新功能,但是需要两周才能完成,第一周你写了50%的代码,如果立刻提交,由于代码还没写完,不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交,又存在丢失每天进度的巨大风险。现在有了分支,就不用怕了。你创建了一个属于你自己的分支,别人看不到,还继续在原来的分支上正常工作,而你在自己的分支上干活,想提交就提交,直到开发完毕后,再一次性合并到原来的分支上,这样,既安全,又不影响别人工作。其他版本控制系统如SVN等都有分支管理,但是用过之后你会发现,这些版本控制系统创建和切换分支比蜗牛还慢,简直让人无法忍受,结果分支功能成了摆设,大家都不去用。但Git的分支是与众不同的,无论创建、切换和删除分支,Git在1秒钟之内就能完成!无论你的版本库是1个文件还是1万个文件。首先,需要了解Git分支内部是怎么运作的。在版本回退中,每次提交Git都它们串成一条时间线,这条时间就是一个分支,这个分支叫主分支master。HEAD严格来说不是指向提交,而是指向master,master才是指向提交的,所以,HEAD指向的就是当前分支。master分支是一条线,Git用master指向最新的提交,再用HEAD指向master,就能确定当前分支,以及当前分支的提交点:每次提交,master分支都会向前移动异步,这样,随着你不断提交,master分支的线也越来越长。当我们创建新的分支,例如dev时,Git新建了一个指针叫dev,指向master相同的提交,再把HEAD指向就表示当前分支在dev上:你看,Git创建一个分支很快,因为除了增加一个dev指针,改改HEAD的指向,工作区的文件都没有任何变化。不过,从现在开始,对工作区的修改和提交就是针对dev分支了。比如新提交一次后,dev指针往前移动一步,而master指针不变:假如我们在dev上工作完成了,就可以把dev合并到master上。Git怎么合并呢?最简单的方法,就是直接把master指向dev的当前提交,就完成了合并:所以Git合并分支也很快~ 就改改指针,工作区内容也不变~合并完成支后,甚至可以删除dev分支。删除dev分支就是把dev指针给删除,删掉后,我们就剩下了一条master分支:真实太神奇了,你看的出来有些提交时通过分支完成的吗?下面开始实战。首先,我们创建dev分支,然后切换到dev分支:$ git checkout -b dev Switched to a new branch 'dev'git checkout命令加上-b参数表示创建并切换,相当于以下两条命令:$ git branch dev $ git checkout dev Switched to branch 'dev'然后,用git branch命令查看当前分支:$ git branch * dev mastergit branch命令会列出所有分支,当前分支前面会标一个*号。然后,我们就可以在dev分支上正常提交,比如对readme.txt做个修改,加上一行:Creating a new branch is quick.然后提交:$ git add readme.txt $ git commit -m "branch test" [dev fec145a] branch test 1 file changed, 1 insertion(+)现在,dev分支的工作完成,我们就可以切换回master分支:$ git checkout master Switched to branch 'master'切换回master分支后,再查看一个readme.txt文件,刚才添加的内容不见了!因为那个提交是在dev分支上,而master分支此刻的提交点并没有变:现在,我们把dev分支的工作成果合并到master分支上:$ git merge dev Updating d17efd8..fec145a Fast-forward readme.txt | 1 + 1 file changed, 1 insertion(+)git merge命令用于合并指定分支到当前分支。合并后,再查看readme.txt的内容,就可以看到,和dev分支的最新提交是完全一样的。注意到上面的Fast-forward信息,Git告诉我们,这次合并是“快进模式”,也就是直接把master指向dev的当前提交,所以合并速度非常快。当然,也不是每次合并都能Fast-forward,我们后面会讲其他方式的合并。合并完成后,就可以放心地删除dev分支了:$ git branch -d dev Deleted branch dev (was fec145a). 删除后,查看branch,就只剩下master分支了: $ git branch * master因为创建、合并和删除分支非常快,所以Git鼓励你使用分支完成某个任务,合并后再删掉分支,这和直接在master分支上工作效果是一样的,但过程更安全。命令总结:在Git中鼓励大量使用分支:查看分支:git branch创建分支:git branch <name>切换分支:git checkout <name>创建+切换分支:git checkout -b <name>合并某分支到当前分支:git merge <name>删除分支:git branch -d <name>
2018年06月29日
199 阅读
1 评论
0 点赞