git多人同步到远端

让我们来看看，两个开发者一起使用同一个共享仓库，会发生些什么。第一个人，John，克隆了仓库，作了些更新，在本地提交。

第二个开发者，Jessica，一样这么做：克隆仓库，提交更新：

现在，Jessica 将她的工作推送到服务器上：（成功，第一个推送的人）

John 也尝试推送自己的工作上去：

John 的推送操作被驳回，因为 Jessica 已经推送了新的数据上去。请注意，特别是你用惯了 Subversion 的话，这里其实修改的是两个文件，而不是同一个文件的同一个地
方。Subversion 会在服务器端自动合并提交上来的更新，而 Git 则必须先在本地合并后才能推送。于是，John 不得不先把 Jessica 的更新拉下来：

用的是fetch命令。

此刻，John 的本地仓库如图 5.4 所示：
虽然 John 下载了 Jessica 推送到服务器的最近更新（fbff5），但目前只是 origin/master 指针指向它，而当前的本地分支 master 仍然指向自己的更新（738ee），所以需要
先把她的提交合并过来，才能继续推送数据：（如果使用的是pull命令，就不需要合并了，pull会自动将远端分支拉到本地，并与本地分支进行合并）

现在，John 应该再测试一下代码是否仍然正常工作，然后将合并结果（72bbc）推送到服务器上：

而在这段时间，Jessica 已经开始在另一个特性分支工作了。她创建了 issue54 并提交了三次更新。她还没有下载 John 提交的合并结果，所以提交历史如图 5.7 所示：

现在，Jessica 可以将特性分支上的工作并到 master 分支，然后再并入 John 的工作（ origin/master）到自己的 master 分支，最后再推送回服务器。当然，得先切回主分支
才能集成所有数据：

要合并 origin/master 或 issue54 分支，谁先谁后都没有关系，因为它们都在上游（upstream）（译注：想像分叉的更新像是汇流成河的源头，所以上游 upstream 是指最新
的提交），所以无所谓先后顺序，最终合并后的内容快照都是一样的，而仅是提交历史看起来会有些先后差别。Jessica 选择先合并 issue54：