• 在这一章中，为了模拟多人合作的场景，我需要一个人分饰两角。

• 执行git clone xx远端仓库地址 xx文件夹命令，在clone代码时指定本地仓库的文件夹名：
  我这里是指定了将拉下来的代码存在test-another文件夹中，和在上一篇博客中产生的test文件夹相区分。也就是说，现在我本地有两个文件夹，test-another文件夹用来模拟另一个同事A的本地仓库，test文件夹模拟我自己的本地仓库。

1.拉取别人同步的代码到本地的流程

• 同事A更新了他的本地仓库代码并同步到了远程仓库：
  假设他新建了一个file1.txt文件。

• 然后同事A将他的本地更改同步到了远程仓库：

• 我执行git pull命令可以将同事同步到远程仓库中的变更拉取下来：

整个流程看上去似乎是比较简单的，但实际工作中在多人合作的情况下却存在着push发生冲突这样的情况。

2.push冲突

发生场景

push冲突通常发生在使用版本控制系统（如Git）进行协作开发的过程中，特别是在多个开发者对同一份代码库的相同部分同时进行修改并尝试推送更改到远程仓库时。以下是两种常见的发生场景：

1. 并行修改同一文件：最直接的情况是，两个或多个开发者同时修改了同一个文件的相同部分，并且每个人都试图将他们的更改推送到远程仓库的同一分支上。由于Git无法自动合并这些冲突的更改，就会出现push冲突。

2. 分支基础已变更：当你在一个分支上工作了一段时间，而在此期间，其他人向该分支的上游提交了新的更改并合并到了远程仓库。这时，如果你没有及时拉取（pull）这些最新更改并合并到你的本地分支，直接尝试推送你的更改到远程，就可能会因为你的分支落后于远程而遇到push冲突。

情景模拟

假设我和同事A同时在各自的电脑上修改本地仓库，并都要将代码同步到远程仓库。

• 同事A创建了一个file-A.txt文件，并先我一步将变更同步到了远程仓库：
  

• 在同一时间，我也在我的电脑上创建了一个file-me.txt文件，我相比同事A晚一步向远程仓库push我的本地变更：
  显示push失败，原因是远程仓库在我修改本地仓库期间已经发生了变化（来自同事A的修改和push）。
  

简单的解决方法

一个简单的方法是先执行git fetch获取远端的最新改变，再执行git merge将远端的变更和本地已经commit的变更进行合并，这样做的方法比较简单，但是可能需要解决一下不同变更之间的冲突。

这样的解决方法比较简单，在要求不高的情况下可以生效。但是实际的多人场景下可能会产生的问题会比现在模拟的场景下多很多，因此从下一篇博客开始会开始介绍更多做法，并解析git命令背后的工作原理。