在本地模拟多用户协同访问版本库。
1、创建一个共享的版本库，利用之前的裸版本库创建方式，不要在新文件夹中直接创建。可以把 F:想象为git://或http://格式，想象它在一台远程服务器上，而不是本机。 
2、在本地模拟两个用户工作区，由不同的用户进行操作，并且想象成从远程克隆版本库。在user1/workspace文件夹中，后面的project表示工作区： 
3、设置版本库级别的username和useremail。以便和全局设置区分开，因为本地模拟环境中所有用户都共享同一全局设置和系统设置，在user1的工作区project中执行： 
会导致版本库.git中的config文件发生变化。
4、在user1的工作区project中新增文件并修改提交： 
5、用户user1将提交推送到共享版本库，origin就是指的 F:\learnTest\Repos\shared.git。推送之后，不再是空版本库: 
6、用户user2克隆版本库，在user2/workspace文件夹执行，克隆后发现工作区多了一个README文件，这就是user1提交推送的文件： 
7、在user2的本地工作区中，设置username和useremail，以区别区间配置： 
8、用户user2的本地版本库现在拥有和user1用户同样的提交。两个用户的工作区是一样的。 
用户user1和用户user2各自在本地版本库中进行独立的提交，然后分别向共享版本库推送：
用户user1先在本地版本库中进行提交，然后将本地的提交推送到远程共享的版本库中：
1、用户user1工作区project中创建team/user1.txt文件，并提交到本地版本库中： 
2、用户user1将本地提交推送到服务器上 
3、查看user1版本库中的日志： 
用户user2不知道用户user1所做的上述操作，仍基于远程版本库旧数据同步而来的本地版本库中进行改动，然后推送到远程共享的版本库。
1、用户user2创建team/user2.txt文件，并提交到本地版本库，注意，文件中的内容不一样： 
2、将user2本地提交推送到服务器： 
user2推送失败，因为这避免了用户提交的相互覆盖。Git通过检查推送操作是不是“快进式”的操作，从而保证用户的提交不会相互覆盖。一般情况下，推送只允许”快进式”推送。
快进式推送是指：要推送的本地版本库的提交是建立在远程版本库相应分支的现有提交基础上的。即远程版本库相应分支的最新提交是本地版本库最新提交的祖先提交。
a、查看用户user2的本地版本库的最新提交及其历史提交： 
b、查看远程版本库的最新提交历史，发现最新提交的哈希值是38a81。不是本地最新提交的祖先提交（也就是不在历史中）： 
进行强制推送：即使是非快进式的推送也会成功执行。但是强制执行，会强制刷新服务器中的版本： 
强制提交后，用户user1向版本库推送的提交会被覆盖。
更好的使用非快进式推送：
1、user2刚刚推送完成后，发现之前文件中内容出现错误，进行修改： 
2、将修改后的文件提交到本地版本库中。
如果采用修补提交会造成前一次提交被新提交抹掉，从而在下次推送时造成非快进式推送（因为远程版本库是最新提交，而如果本地提交被抹掉，那远程提交就不是本地提交的祖先提交，本地提交把它给抹掉了）。但是如果没有其他人获取远程版本库中的最新提交，那还是使用修补提交。然后强制推送到远程版本库： 
3、采用强制推送，更新远程共享版本库中的提交 
4、查看本地版本库和远程版本库提交历史： 
合并后推送
1、用于user2的强制推送，导致user1上午提交被覆盖。用户user1发现遇到非快进式推送： 
2、用户user1运行git pull命令，它包含两个动作：获取远程版本库的最新提交，以及将获取到的远程版本库提交与本地提交进行合并： 
3、合并之后，查看版本库的提交关系图，合并之后发现提交cea177d成为当前最新提交（合并提交）的父提交之一： 
4、再执行推送操作，就能成功： 
5、查看本地和远程版本库的哈希值： 