git系列：进一步讲讲git的分支管理-ag真人游戏

•写在前面

git分支管理在前面说了，非常方便我们开发，没看过前面的可以到前面看这篇git分支管理，接下来，我们讲讲关于分支管理的其他指令，帮助我们进一步了解分支管理给我们带来了什么方便。

冲突是什么？很多时候，当你在分支上进行修改，或者进行多人协同开发的时候，你会需要使用git进行合并，合并的时候就会出现冲突，也就是在你要合并的分支上发生了你这边没有更新的修改，并且同时这一个分支也发生了修改，两个分支的某一些文件存在不一致的情况，就会发生冲突。一般合并若发生冲突，git会告诉你哪些文件发生了冲突，如下：

$ git merge branch1
auto-merging readme.txt
conflict (content): merge conflict in readme.txt
automatic merge failed; fix conflicts and then commit the result.

这里告诉你说readme.txt文件发生了冲突，你也可以使用git status指令查看发生冲突的相关文件，那我们知道冲突之后，我们需要怎么解决呢？很简单，首先我们在没有使用工具的情况下（比如idea等，idea提供了很强大的工具让我们配合使用git，这文章不是讲解idea的使用，所以这里就不多说了，以后有机会专门开工具篇再说），直接打开发生冲突的文件，一般会出现下图这样的情景：

在1区间，也就是<<<<<>>>>>branch1之间的代码是我们分支上最新的代码，这个时候你只要取舍其中一个区间就可以解决冲突，一般情况下都是保留最新的更新，也就是第2区间。删的时候注意把我上右图圈住的都删掉哦。

删除冲突之后，你只需要重新git add 和git commit，把修改提交一下就可以了，冲突就解决了。然后就可以开始你的合并了。你可以使用如下指令查看分支的合并情况。

$ git log --graph --pretty=oneline --abbrev-commit

在实际的开发中，我们通常会创建不同的分支代表不同的开发环境，就拿我以前工作经验看，公司开发的分支会有四条主线，分别是master、release、stage三种环境，master是用于测试环境，一般自己新开发完的功能代码可以合并到这个分支，然后重启运行项目用于测试、release分支是线上分支，也就是目前开发的项目正在运行的环境，这个分支一般情况下不是谁都有权限进行合并的，毕竟线上正在运行的项目代码万一被搞乱了，简直是爆炸。stage分支是预发分支，也就是master分支上测试好的代码，可以合并到这个分支上，用于测试人员使用。这三条主分支上，你可以在这三条主分支上创建自己的分支，每个人都可以创建自己的分支，非常适合团队合作，所以协作起来可能长这样，是不是很刺激。

听到bug是不是很令人头痛，在我们日常的开发中不可避免的会遇到bug，如果我们在开发自己的功能，还没有开发完的时候临时要处理一个bug怎么办，这个时候我们正在开发的代码功能还没有写完，不能提交，但是这个bug又需要我们停下手上的工作区解决，这个时候怎么办？ok，完全不要担心，git之所以强大，就是它考虑了很多我们实际开发中可能会遇到的情况，git对于这种情况，提供了一个stash功能，可以把当前工作现场“储存”起来，然后以后继续工作。使用如下指令。

$ git stash

执行指令之后你可以使用git status查看当前工作区，就是非常干净的，因此可以开始着手修复bug。首先确定要在哪个分支上修复bug，假定我们正在request分支（request分支是在master上创建的）上开发代码，需要在master上修复，我们就从master创建临时分支，这个时候你在这个临时分支上。创建分支之后，你就可以开始修复bug，修复完成之后，可以切换到master分支，并完成合并，最后删除这个临时分支，bug毫无多余痕迹的修复了。然后这个时候我就就可以切回request分支上了，但是request分支上的工作区非常干净，我们把原来的工作储存到哪里去了呢？我们可以使用一下指令查看，发现工作区还在，那么我们有两种方法恢复。

$ git stash list

$ git stash apply
#可以使用这个恢复，恢复后，stash内容并不删除，你需要用
$ git stash drop #来删除；
#另一种方法是使用这个，恢复的同时把stash内容也删了
$ git stash pop

在master分支上修复了bug后，我们要想一想，dev分支是早期从master分支分出来的，所以，这个bug其实在当前dev分支上也存在。那怎么在dev分支上修复同样的bug？重复操作一次，提交不就行了？有木有更简单的方法？有！同样的bug，要在dev上修复，我们只需要把4c805e2 fix bug 101这个提交所做的修改“复制”到dev分支。注意：我们只想复制4c805e2 fix bug 101这个提交所做的修改，并不是把整个master分支merge过来。为了方便操作，git专门提供了一个cherry-pick命令，让我们能复制一个特定的提交到当前分支。git自动给dev分支做了一次提交，注意这次提交的commit是1d4b803，它并不同于master的4c805e2，因为这两个commit只是改动相同，但确实是两个不同的commit。用git cherry-pick，我们就不需要在dev分支上手动再把修bug的过程重复一遍。

多人在同一个分支上协作时，很容易出现冲突。即使没有冲突，后push的童鞋不得不先pull，在本地合并，然后才能push成功。每次合并再push后，会出现前面我放的那张图那样很乱的类似路线图的东西。git有一种称为rebase的操作，有人把它翻译成“变基”。

git的分支管理是不是很强大，到这里了，你有没有爱上git这款工具，如果爱上了，证明你已经能够使用了，还没爱上只能说明还不够了解，哈哈哈哈。