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

前言

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

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

一、git协作方式

1.常见开发模式

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

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

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

  合并方向为：develop -> test -> master

2.SVN方式（典型模型）

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-3dhgopmN-1587025392258)( http://ahuntsun.gitee.io/blogimagebed/img/git/lesson6/1.png)]

首先有两位用户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