第六讲：Git协作与Git pull常见问题

前言

git除了可以很好地管理个人项目外，最大的一个用处就是实现团队协作开发。况且，linus大神开发git的初衷就是为了维护Linux内核这一开源项目。所以，熟悉使用git进行多人协作开发的一般步骤和方法具有十分重要的意义。这一讲将会为你介绍使用git进行团队协作开发的一般方式以及git pull操作常见问题的解决方法。

一、`git`协作方式

1.常见开发模式

Gitflow：简单来说，就是多种开发模式的总称。例如：使用多少分支，什么时候合并分支等等。这方面篇幅较长，内容较多，之后会进行详细讲解；
基于Git分支的开发模型：一般最少有三个分支：

合并方向为：develop -> test -> master
- develop分支：频繁变化的分支，供开发人员之间进行协作开发，文件推送与合并；
- test分支：供测试人员与产品等人员使用的一个分支，变化不是特别频繁；
- master分支：生产发布分支，变化非常不频繁的一个分支（一般有权限设置，因为直接与生产有关）；
- bugfix(hotfix)分支：用于紧急修复的分支；当出现紧急bug时，在常规的develop分支上修复已经赶不上了。此时可以直接将master分支的代码拉取到bugfix分支上，进行bug修复，修复完之后，再将它合并到master分支上发布；

2.`SVN`方式（典型模型）

首先有两位用户A与B，A的本地仓库「不为空」，B的仓库「为空」，还有一个远程仓库C。

A首先将本地仓库的代码推送（push）到C中，此时A和C两个仓库的文件一致，如图中1所示；
随后B将C的代码拉取（pull）下来，如图中2所示，此时A，B，C三个仓库中的文件一致；随后A，B继续在本地进行开发，并向各自的本地仓库进行了数次提交；
此时，A先向C推送修改过后的本地仓库文件，由于这是远程仓库C的首次修改，C中的文件A中都有，所以可以直接推送，不用先执行git pull，如图中3所示；
随后，在B将修改过的本地仓库文件推送到C的过程中会出现错误。原因在于：此时的C中有A做出的修改，不能让B进行覆盖，此时B要想成功推送，应该先将C中的文件拉取（pull）到本地；如图中4所示，拉取时有两种情况：
- 「成功」：说明A与B修改的不是同一个文件，采用Fast-forward方式自动合并；
- 「失败」：说明A与B修改了同一个文件，需要手动解决冲突并合并；
B成功将C中的文件拉取到本地合并后，就能将B对本地仓库所做的修改推送（push）到远程仓库C了，如图中的5所示；

在整个过程中，可以发现远程仓库C仅仅是起到「代码第三方托管」的作用；

3.模拟多人协作

为了模拟多用户协作，可以使用--local来设置每个仓库的用户信息：

git config --local user.name '张三'

--local是一个配置作用域的参数，其他的还有：

--global：作用域为每个计算机用户，优先度第二，实际上常用这个参数进行配置；
--system：作用域为整个系统，优先级最低；

可以使用：git clone将远程仓库的代码下载到本地某文件夹中，下面使用的是SSH的方式：

还可以通过在链接后面加上一个字符串，重新命名下载到本地的远程仓库文件的名字：

git clone git@gitee.com:ahuntsun/MY.git mygit2

4.协作的本质

远程仓库通常有多个分支，而在本地仓库进行一次推送时「并不是将本地仓库的所有分支都推送到远程仓库」，而是选择本地仓库中的一个分支，将其推送到远程仓库的其中一个分支上：

比如本地的master分支，如上图所示，可以选择远程仓库的master、dev、test其中一条分支进行推送。假如想要推送到远程仓库的master分支，如果一开始两个分支没有任何联系，自然要：

①先建立本地master分支与远程master分支的关联（至于如何建立关联，下一节将会详细讲解）；
②通过本地master分支与远程master分支的合并，使两条分支的内容第一次达到同步；
③在本地master分支上进行修改，然后将修改推送到对应的远程master分支上。此时，两分支的内容第二次达到同步；

二、`git pull`

在实际开发中，在推送代码前，往往都要先执行一次git pull将远程仓库的代码拉取到本地并进行合并；从前面的学习中我们知道：git pull = git fetch + git merge：

git fetch：表示将远程仓库的所有文件拉取到本地版本库；
git merge：将远程仓库中的文件与本地仓库中的文件进行合并；

但是，在执行git pull命令时，由于本地仓库与远程仓库历史提交记录的不同，往往会出现各种各样的合并错误；在分析这些错误之前，首先搭建测试环境：

分别创建两个本地仓库mygit和mygit2，并且这两个本地仓库与同一个远程仓库建立联系，如下图所示：

1.不发生合并冲突

在本地仓库mygit2中使用--local参数配置新的用户lisi模拟多人协作，随后通过lisi给远程仓库推送一个新的文件。回到mygit后执行git remote show origin指令，会显示如下信息：

表示，本地仓库mygit相对于远程仓库而言已经过时了，即远程仓库中有mygit2推送的，mygit中没有的文件；此时可以在mygit中执行git pull，将远程仓库中的文件拉取到本地仓库mygit中进行合并：

上图中的第二个箭头表示，在pull操作的过程中mygit中的master分支与远程仓库中的master分支采用Fast-forward方式进行了合并，并达到了同步。

❝
这里的本地远程分支origin/master代表着远程master分支，关于本地远程分支将会在下一节进行详细讲解；
❞

关于Fast-forward方式之前已经介绍过了，在上述合并过程中origin/master分支直接指向了最新提交，中间没有其他分支，也就不会出现合并冲突，这种合并方式称为「快进」。如下图所示：

这是一个理想的情况，很多情况下执行git pull操作时，都会出现合并冲突，需要解决冲突，再进行手动合并；

2.`git pull`同源合并冲突

所谓同源，指的是本地仓库与远程仓库中的分支从根提交节点开始，有共同的提交历史；简而言之，有共同的根提交节点的两个分支称为同源；如下图所示，两仓库中的master分支有共同的根提交节点A，所以这两个仓库的master分支是同源的：

这种情况下git pull出现的错误为自动合并失败，比如都同时修改了develop.txt文件，错误信息如下：

Auto-merging develop.txt
CONFLICT (content): Merge conflict in develop.txt
Automatic merge failed; fix conflicts and then commit the result.

错误原因

具体情况模拟如下：

在mygit中修改hello.txt文件的第二行为1，在mygit2中修改hello.txt文件的第二行为2，即对同一文件的同一处进行了修改。

此时取决于谁先进行git push操作，若mygit先将修改后的hello.txt推送到远程仓库。那么当mygit2再进行推送时会出现如下错误：

提示信息表明：远程仓库中有一些文件是你没有的，无法更新远程仓库；这是因为，mygit先把修改的hello.txt推送到了远程仓库；此时mygit2想要成功进行推送，需要先将远程仓库中经过mygit修改的hello.txt与本地仓库的hello.txt进行合并。

解决方案

可以使用git pull来解决这一问题，那么我们首先执行一次git pull操作：

可以发现git pull指令在进行自动合并时发生了错误，这是因为mygit和mygit2都对hello.txt的同一个地方做了修改，git不知道以谁为准，所以会导致自动合并失败，此时需要通过「解决冲突三步曲」来手动合并：

「第一步：」

打开冲突文件hello.txt可以看到典型的冲突文件显示方式：

箭头<<<与>>>范围内表示的是发生冲突的位置。2是mygit2对hello.txt的修改，1为远程仓库中hello.txt的内容；

经过协商后，留下第3行，其余删除：

由此手动合并了对文件hello.txt的修改，解决了冲突。

❝
vim指令补充：通过esc进入命令行模式后，通过上下方向键选中某一行，再双击d就可以删除光标所在的行；删除多行时，在命令行中输入:2,4d表示删除第2~4行；
❞

「第二步：」

再次查看状态：

发现hello.txt处于工作区，git提示我们要通过git add指令将解决冲突时对hello.txt所做的修改纳入暂存区。

「第三步：」

执行完git add之后，再进行提交git commit:

由此，解决了冲突；

从上图中箭头所指内容可以看出：本地仓库mygit2中的master分支已经比本地远程分支origin/master分支多了两次提交。由于origin/master分支代表着远程仓库的master分支，也就是说本地仓库mygit2中的master分支比远程仓库的master分支领先了两次提交；过程如下图所示：

首先mygit在提交1st的基础上进行了第2次提交（修改hello.txt），之后mygit将本地仓库推送（push）到远程仓库；
此时mygit2同样在本地仓库中进行了一次提交3rd（修改hello.txt），此时推送到远程仓库会出现错误，需要进行pull操作；
当mygit2执行pull操作，将远程仓库拉取到本地后，由于发生冲突，所以暂时不会将origin/master的指向更新到最新提交；随后，在mygit2中手动解除冲突并进行合并后，mygit2的状态为：

可以看到解决冲突，手动合并后，mygit2已经往前更新了两次提交，而此时origin/master仍然指向提交1st。

所以解决冲突后，mygit2中的master分支会比origin/master分支领先两次提交；再次执行git push后，origin/master分支就会指向最新的提交点4th了，此时三个仓库的状态为：

在实际开发当中，难免会出现多个人修改了「同一个文件」的情况，在进行手动合并的过程中一定要与对方协商应该如何合并，而不是「直接覆盖」；

3.`git pull`不同源合并冲突

所谓不同源，指的是两个仓库中的分支，根提交节点不同，如下图所示：

假如本地master分支要将内容推送到远程master分支。由于本地master分支根提交节点为1st，远程master分支根提交节点为A，两个分支没有公共的父提交节点。所以，无法进行合并。这种情况下执行git pull会出现以下错误：

There is no tracking information for the current branch.
Please specify which branch you want to merge with.

❝
特殊情况：假如本地仓库mygit是空的，也会发生不同源合并冲突。
❞

错误原因

简单来说git pull失败的原因有两点：

「第一点」：两仓库中的master分支由于根提交节点不同，没有共同的提交历史。所以，会导致采用「三方合并原则」合并分支时，找不到公共提交节点而无法合并：

「第二点」：本地master分支没有与远程仓库中的任一分支建立关联。因此，本地master分支不知道将文件推送给谁，这样自然会失败；

解决方案

知道了git pull失败的两点原因，解决方案就很清晰了，同样分为三步：

「第一步」：执行一次git pull将远程仓库的分支拉取到本地：

image-20200411211023424

这里的本地远程分支origin/master和origin/dev是远程分支master和dev的本地形式，代表着它们，内容上与它们一致。虽然git pull失败了，但是我们获得了远程分支的信息，方便进行第二步的合并操作；
「第二步」：创建两分支的公共提交历史。此时两分支没有公共父节点，不能采用merge方式合并。应该采用rebase变基的方式，将本地master分支追加到远程master分支后面。由于本地远程分支origin/master与远程master分支有这相同的提交历史，所以可以这样写：
```
git rebase origin/master
```
此时，本地master分支的提交历史变为：A <- B <- 1st <- 2nd。这样本地master分支与远程master分支就有了公共的提交历史，即转换为了同源分支：

image-20200411222958428
❝
「简写」：可以将第一步和第二步通过参数的形式合并为一步操作：
```
git pull --rebase origin master
```
image-20200411222302708

❞
「第三步」：建立本地master分支与远程master分支的关联。常用的有以下三种方式：
```
//格式
git branch --set-upstream-to=origin/ master
//用在这里具体为
git branch --set-upstream-to=origin/master master
```
该指令作用为，将本地master分支相关联的远程分支设置为远程master分支，执行该指令后，通过git branch -vv查看分支的关联情况，可见已顺利建立关联：

image-20200411213556267

之后就可以进行推送了：

image-20200411213920987
```
git push -u origin master
```
该指令作用为：建立本地master分支与远程master分支的联系，并进行推送：

image-20200411215931617
```
git push --set-upstream origin master
```
作用为：建立本地master分支与远程master分支的联系，并进行推送：

image-20200411221552193
- 「方式三」：
- 「方式二」：
- 「方式一」：

实战演示

创建两个仓库mygitA和mygitB，首先在mygitA中的master分支上添加A.txt，提交信息记为A：

在mygitA中创建并切换到dev分支，添加文件C.txt，并进行提交，提交信息记为C：

切换回mygitA的master分支，添加文件B.txt，并进行提交，提交信息为B：

此时`mygitA`中两分支的状态如下：

随后，建立本地仓库mygitA与远程仓库的关联：

image-20200410130748140
设置并推送mygitA的master分支和dev分支，到远程仓库的master分支和dev分支上：

image-20200410232136808
回到mygitB，添加文件1st.txt和2st.txt并进行两次提交1st和2nd：

image-20200410232755681