当两个对等体同时将更改推送到同一个远程时,git如何工作

Question

我是git的新手,我通常使用具有中央存储库的P4,而git是分布式VCS.

我感兴趣的是当两个对等体同时将更改推送到同一个远程时git如何工作.假设每个对等体在推送之前解决了所有冲突.我想如果git报告冲突,后者将被拒绝!

但是,根据我的理解,git在内部是一个键/值存储,就像当前流行的NOSQL数据库,尤其是支持p2p复制的Couch-DB.

其实我想问一下,在客户端将更改推送到远程git存储库的情况下,git进程如何冲突？推被拒绝了吗？

从马克的答案来看,我认为推动应该被拒绝.

Answer 1

简短的回答

是的,其中一个推动将被拒绝 - 无论哪个推迟,即使它只是一微秒,正如Jefromi在他的评论中提到的那样.但是,它将被拒绝,因为远程存储库看到后一个推送的历史记录不包括前一个推送的历史记录,而不是因为它看到正在推送的内容中的任何冲突.

更详细的答案

如果在Git术语中它不会"快进"分支,通常会拒绝推送.这意味着,如果你的主人是在A和远程仓库的是B,然后推只会如果B是A的祖先(我说"通常",因为你可以添加选项,以"力"推,如果成功远程存储库允许这样做,但这不是典型的情况.)

在您描述的情况下,假设所有三个存储库最初具有相同的历史记录:

P -- Q -- R

你添加了一个提交S:

P -- Q -- R -- S

...而其他人添加了提交T:

P -- Q -- R -- T

如果其他人冲撞时抢先一步(即,Git的服务器上处理自己的推第一),然后他们推将被接受,因为R是的祖先T,所以后来远程仓库也将使用历史P -- Q -- R -- T.如果您随后尝试推送,则会出现错误,因为T它不是其祖先S.通常,在看到该! [rejected]错误时,您将运行git pull或git pull --rebase确保您在远程存储库中领先于master.

git pull将创建一个合并提交M,使您的历史记录看起来像:

P -- Q -- R -- T -- M
           \       /
            -- S -

...同时git pull --rebase将重新应用您在T创建新提交时引入的更改,S':

P -- Q -- R -- T -- S'

在其中的任意一种情况下,你应该能够再次推,因为T是双方的祖先M和S'.(假设没有其他人同时再推!)

通过仅允许快进,永远不必解决远程冲突 - 如果有任何冲突,您将被提示在运行时在本地解决它们git pull.

值得注意的是,响应推送而应用于远程存储库的更新是原子的,因此在我们上面描述的示例情况中,在同一时间推送S和T推送的情况下,它始终是这样的情况之一.它们是完全应用而另一个会失败,没有效果.

关于键/值存储点的说明

虽然Git的对象数据库是作为键/值存储实现的,它将对象名称(也称为哈希或SHA1sums)映射到对象的内容,但根据我的经验,人们学习Git很容易对Git的表现做出令人困惑的假设.他们听到"这就像一个关键的价值存储" - 听起来好像这可能发生在你的情况下,所以我建议在这个层面思考Git并不是理解这个问题的最有用的方法.