Git：学习笔记(四)—分支

分支

我们在前面的博客中提到过分支这个概念，比如说master分支，分支在Git中是非常重要的，假设你准备开发一个新功能,但是需要两周才能完成,第一周你写了50%的代码,如果立刻提交,由于代码还没写完,不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交,又存在丢失每天进度的巨大风险。现在有了分支,就不用怕了。你创建了一个属于你自己的分支,别人看不到,还继续在原来的分支上正常工作,而你在自己的分支上干活,想提交就提交,直到开发完毕后,再一次性合并到原来的分支上,这样,既安全,又不影响别人工作。

创建与合并分支

在之前的版本回退中，我们知道了Git将每次提交连接成一条时间线，这条时间线就是分支，在刚开始只有一条分支，就是我们的master分支，并且HEAD指针指向master分支，即当前分支，其时HEAD并不是指向提交的，它是指向master，而master指向分支上的每次提交，一开始，master是一条分支线，master指向最新的一次提交，然后HEAD指向master，这样就可以确定当前分支，以及当前分支的提交点，每次提交，master都会向前移动一步，随着不断的提交，master的分支线不断加长，但我们创建一个新的分支时，比如创建一个dev分支，Git就会生成一个dev指针，并且指向与master相同的一个提交点，当我们切换到dev分支时，HEAD指针就会指向dev，这是当前分支就成为了dev，因此，在Git中，分支切换的速度是非常快的，因为只需要将HEAD指针指向所要切换的分支即可，分支切换后，接下来对当前工作区的修改的添加与提交就会都是针对新分支的了，每次提交，dev指针向前移动一步，而master指针不变。

如果我们在dev分支上的工作做完了，那么我们就可以将分支切换到master分支，然后将dev分支合并到master分支，怎么合并呢，Git的话就非常的简单了，直接将master指向dev的当前提交就可以了，这样就完成了合并
这样就可以看出来，Git分支的合并也是很快速的，就只是改改指针的位置，工作内容也不改变。合并完成后如果不再使用dev分支。我们可以将它删除，这样就又会只有master一条分支了

实战一下

1、创建并切换分支
git checkout -b dev #这条命令直接创建并且切换dev分支，相当于下面两条命令：

git branch dev			# 创建分支
git checkout dev		# 切换分支

2、查看当前分支
git branch

其表示共有两条分支，当前分支为dev，HEAD指针指向dev，现在我们就可以在dev分支上正常提交，比如现在对README.txt文件做一个修改，随便添加一行：
“Create a branch dev is quick”
然后添加修改并提交

接下来我们切换到master分支，查看README.txt内容：

看见没，master分支工作区的内容并没有改变，现在的分支状态是这样的：

3、下来，我们将dev分支合并到master分支，首先先将分支切换到master ，然后使用命令 git merge dev 将dev分子合并到master

注意上面输出中的“Fast-forward”信息，Git告诉我们这次合并是“快进模式”，也就是直接把master指向dev的提交，所以速度非常快，也有其他方式的合并，后面再说，合并完成后，不用dev的话，就可以将其放心的删除了：
git branch -d dev

解决冲突

分支的合并往往不都是一帆风顺的，其中总会出现一些问题，下面我们创建一个新的分支feature1来继续我们的工作：
1、创建并切换feature1分支

2、修改README.txt文件，修改最后一行为：
“Create a branch feature1 is quick and simple.”
修改完成后添加修改并提交

3、切换到master分支，并修改README.txt文件最后一行为：
“Create a branch feature1 is quick & simple.”
修改完成后添加修改并提交

现在分支的状态应该就变成这个样子了：

master与feature1分支都有自己的最新提交。
4、尝试在master分支上合并feature1分支，我们想一下，这种情况下指针该怎样移动，应该会出现冲突吧，先来看看结果：

果不其然，Git告诉我们，README.txt文件存在冲突，必须手动解决之后再提交，使用git status也可以告诉我们是哪个文件冲突了，他说手动解决，那么该怎样手动解决呢，我们看看这个冲突的文件内容：

文件中，为我们指出了当前分支下该文件的内容与feature1分之下该文件的内容，现在让我们手动解决的话，就是让我们自己统一一下文件内容，我们将其修改为下面这样：

然后再次进行提交：

现在分支的状态应该是这样的：

使用git log也可以查看当前分支状态：

多人协作

当你在本地从远程仓库克隆时，Git就自动将本地master分支与远程master分支对应了起来，并且，远程库的名称是origin，可以使用git remote查看远程库名称，加上-v选项的话，会显示详细信息

上面显示了可以抓取和推送的 origin 的地址。如果没有推送权限,就看不到push的地址。

推送分支

推送分支就是将该分支上的所有提交推送到远程库，推送时，要指定本地分支，这样Git就会把该分支推送到与远程库对应的远程分支上：
git push origin master
如果要推送其他分支，比如dev，就改成：
git push origin dev
也并不是所有的分支都要向远程推送，那么哪些需要，哪些不需要呢？
1、master分支是主分支，要时刻与远程保持一致；
2、dev分支是团队协作开发的分支，也要与远程保持一致；
3、bug分支只用于修复本地bug，没必要推送到远程；
4、feature分支如果没有团队在上面协作开发的话，就不需要推送到远程。

抓取分支

在多人协作时，团队人员都会将自己的修改提交推送到master和dev分支上，现在，我们开启另外一台虚拟机并安装Git，来模拟一下团队协作，将新开启的虚拟机的ssh-key添加到github，现在使用新开启的虚拟机来从远程库克隆

默认情况下，新的虚拟机只能看到master分支，可以用git branch查看

现在，你的同事要在dev分支上开发，所以就要创建远程origin的dev分支到本地，使用下面的命令创建：
git checkout -b dev origin/dev

现在它就可以在dev分支上修改，并不时的将dev分支push到远程

你的同事已经向origin/dev分支推送了他的提交，恰好，你现在也对同样的文件做了修改，并且尝试向远程推送

推送失败，这是因为你同事的最新推送的提交与你尝试推送的提交有冲突，解决办法也很简单，Git提示我们，需要将远程最新的提交使用git pull抓取下来，然后在本地合并，解决冲突再推送：

git pull也失败了，原因是没有设置本地dev分支与远程origin/dev分支的连接，根据提示设置：

然后再进行pull

拉取下来后进行手动合并，解决冲突后进行推送，解决冲突的方式跟之前分支管理中解决冲突的方法一样，解决完后就可以推送了