一台安装了Git并可以连接网络的电脑（多个本地仓库模拟多人协同办公）
一个创建了远程仓库的GitHub账号
我们还是通过两个本地仓库模拟两个协同工作的用户，他们一个配置的用户名是 ZhangSan 一个配置的用户名是 LiSi ，并且两者均工作在 mileStone 分支上(图示)。
ZhangSan 开始工作了，其先运行 git pull 进行更新（注意 ZhangSan 本地配置的远程仓库别名为默认的 origin 因此这里可以直接使用 git pull ）, 然后修改了文件 “1.GIT_Basic_Command_List.txt”（图1示），并提交到了本地仓库（图2示）！当准备push的时候，ZhangSan突然感觉口渴了，出去喝了杯茶，顺带和前台聊了个天......（杯具就这样产生了....）
LiSi 在走查代码的时候，也发现了这个问题 (git reset --hard 命令比较危险，需要警示)，于是心地善良的他，也准备修改一下这个文件！ 他也是先 git pull GitHub mileStone 一下（注意 LiSi本地仓库配置的远程仓库别名不是默认的 origin，运行这个命令需将命令写全），然后同样修改了文件 “1.GIT_Basic_Command_List.txt”（图1示），同样进行了提交，和ZhangSan不同的是，LiSi没有口渴，提交完后直接就执行 push 操作了，该操作也顺利完成了（图2示）！
ZhangSan 茶喝了，天聊了，舒舒服服来到工位，突然想起来，刚刚有点变更忘记推送了，赶紧的吧，万万没想到的是， 推送竟然失败了.....（图1示）。因为这种情况也不少见，基本就是因为有人向远程仓库推送了内容，先 git pull 一下吧，但万万没想到，又报错了！ 从提示信息上看，Git发现远程仓库和ZhangSan本地仓库的变更是在同一个文件上，于是尝试自动merge这些变更，但因为变更发生在同一区域，冲突了，自动merge无法进行！需要我们手动处理，并再次提交！（图2示）
Git会将冲突信息完整体现在ZhangSan本地仓库的工作区中（对应的文件内容上，图1示），这时，我们要做的就是和已经推送相关内容的同事（此处是LiSi）进行沟通，协商这块内容该如何处理，双方达成一致后，ZhangSan 可以大刀阔斧的动手了，修改完毕后（图2示），再次提交到本地仓库，并及时推送到远程仓库（图3示）！
此时大家或许有个疑惑，那 LiSi 现在那边会出现什么状况呢？ 因为ZhangSan合并了一下冲突，并再次推送了内容，此时 LiSi 如果运行 git pull 操作，会自动合并么？ 难道还会有冲突（那就进入死循环了）？ 请相信Git的强悍，这时 LiSi 再次运行 git pull 更新操作是不会有问题的！（图示）
我们再使用Git进行工作时，工作前请一定先运行 git pull 命令更新一下本地仓库的工作分支
git pull 对于冲突首先会尝试自动合并（同一文件不同区域的变更通常会自动合并成功），当自动合并失败，会报错，并提示用户进行手动合并