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



  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值