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命令可以看到分支合并图。

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>