记得我已经花了一年时间研究同样的问题,我觉得至少要留下一条笔记才能放心离开。毕竟这是一个很好的问题。
考虑到问题中的“分布式”是指有一个中心节点的系统,那么Git对基础设施政治非常不偏不倚。
它本身既不是集中式也不是分散式,它是一个完全功能的块链,并且是离线的。
虽然在离线状态下它有潜力成为分布式和分散式,但在用户推送或从远程拉取之前都不是。
Git还支持多个远程,因此在集中管理模式下使用Git并不会限制其分散能力。
我们之所以使用带有中央枢纽的Git是因为尚不存在一种去中心化的替代品,可以提供与云平台类似的成本效益和便利性。
但是,确实存在有效的分布式远程:
hypergit创建了一个指向一对多(单作者)点对点网络的git远程,使得源自中心节点的提交分布无服务器。
如果你和几个朋友决定创建自己的个人hypergit端点,并在进行推送之前都同意尝试从每个人的端点获取;那么你们之间就有一个完全去中心化的解决方案。
然而,你会很快发现,这种模型难以扩展,在参与者数量增加时同步复杂性呈指数级增长。
为了澄清问题:在上述模型中,我们引入了一个天真的全局时间锁定,以降低合并冲突的风险——由于Git没有“自动冲突解决策略”,默认行为是引发警报,并让用户手动纠正任何合并冲突。但是,如果你和你的朋友无意中解决了相同的合并冲突,甚至可能产生了不同的结果,该怎么办?
在集中式系统中,这是一场有点不公平但熟悉的竞赛——谁先成功将非冲突提交推送到origin/master
就可以先回家了。但是,当存在多个远程源时,该怎么办?
或者作为一个包含冲突合并冲突解决的Git swarm中的初级开发者,我如何知道从哪个节点拉取最新的非冲突状态?我可能会站起来问:
“我看到到处都是冲突,你们中谁有最新的非冲突状态?”
经过一番讨论后,几个人应该指向一个远程源。也就是说,团队达成了使用谁的主分支的共识。
在一个完全去中心化的系统中,打断邻居并达成共识所需的时间足够长,以至于新的提交足以生成完全不同的一组需要解决的冲突。
因此,为了解决这个问题,我们运用一点群体智慧,为每个节点配备了“自动冲突解决策略
按照先后顺序包含最近提交的分支应被视为主干。
(忽略没有一个时钟显示相同时间的事实)我们可以使用以下简单的一行代码聚合git log的输出以生成可比较的向量时钟:
ruby -e 'puts `git log --full-history --reverse "--format=format:%at;%an--%ae"`.split("\n").reduce({min: {}, d: {}}) {|out, line| t, a = line.split(";"); out[:min][a] = [t.to_i, out[:min][a] || t.to_i].min; out[:d][a] = t.to_i - out[:min][a];out}[:d].values.sort{|a,b| b <=> a}.join(":")'
这将允许每个节点在冲突时始终知道要选择哪个 HEAD
,而无需打扰其邻居。
通过自主解决冲突,我们在理论上解决了之前的扩展问题,并且现在可以放弃所有单独的swarm-endpoints,转而使用一个多对多稀疏连接的swarm,在其中提交按照策略进行转发、合并和丢弃,以 分散化 的方式处理。
Git 现在是一个区块链(TM)
...
我目前正在研究“离线优先”软件设计,编写了一个纳米级共识自由离线区块链,但在尝试撰写报告时卡住了。
将某些东西描述为:“...与Git的分散化方式相同”就感觉不对。
因此,我通过搜索“Git是否被认为是分散化的?”找到了这个问题。
嗯,除非有人纠正我,否则我别无选择,只能在这个背景下宣布自己是专家,并说:
简而言之;
Git本质上既不是分散化的也不是分布式的,它是离线的,就像一个现实中的git一样,并不在乎。
如果我可以为这个主题添加一个段落,那么以下两个项目说明了Git“链”可以用于承载任意功能,它们直接利用并丰富了 Git 的分布式和去中心化使用潜力。
git-dit
sit
commit
(一个加密的数据块)都附加在一个“父”提交(另一个块)上,也称为追加日志。所谓的“区块链”通常指试图达成全球共识的软件。如果问“如何在 P2P 群集上运行 Git?”会更有趣。 - telamon