Git应用详解第六讲：Git协做与Git pull常见问题

前言

前情提要：Git应用详解第五讲：远程仓库Github与Git图形化界面

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

1、git协做方式

1.常见开发模式

• Gitflow：简单来讲，就是多种开发模式的总称。例如：使用多少分支，何时合并分支等等。这方面篇幅较长，内容较多，以后会进行详细讲解；

• 基于Git分支的开发模型：通常最少有三个分支：

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

  合并方向为：develop -> test -> 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分支上。此时，两分支的内容第二次达到同步；

2、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将远程仓库的分支拉取到本地：

  这里的本地远程分支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分支就有了公共的提交历史，即转换为了同源分支：

  简写：能够将第一步和第二步经过参数的形式合并为一步操做：

  git pull --rebase origin master

• 第三步：创建本地master分支与远程master分支的关联。经常使用的有如下三种方式：

  • 方式一：

  //格式
  git branch --set-upstream-to=origin/<branch> master
  //用在这里具体为
  git branch --set-upstream-to=origin/master master

  该指令做用为，将本地master分支相关联的远程分支设置为远程master分支，执行该指令后，经过git branch -vv查看分支的关联状况，可见已顺利创建关联：

  以后就能够进行推送了：

  • 方式二：

  git push -u origin master

  该指令做用为：创建本地master分支与远程master分支的联系，并进行推送：

  • 方式三：

  git push --set-upstream origin master

  做用为：创建本地master分支与远程master分支的联系，并进行推送：

实战演示

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

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

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

​ 此时mygitA中两分支的状态以下：

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

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

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

此时三个仓库的状态为：

若想将mygitB的master分支推送到远程仓库的master分支上，按照上文的讨论，采用简写形式，可经过如下两步进行实现：

• 第一步：经过rebase合并本地master分支与远程master分支：

git pull --rebase origin master

执行完上述指令后，mygitB的状态为：

• 第二步：创建本地master分支与远程master分支的联系，并进行推送：

git push -u origin master

如图所示，与远程分支创建了联系，并完成了推送；由此解决了因为不一样源形成的pull操做冲突。

以上就是本节的所有内容，细心的你确定发现了，在这一节中偶尔会提到本地远程分支origin/master，它究竟是什么呢？有什么做用？其实它是git进行本地仓库与远程仓库交流的一个重要桥梁。在下一节中将会为你详细介绍本地远程分支的由来和做用，以及最重要的：如何创建本地仓库与远程仓库的分支对应关系？咱们下一节再见！