我知道Git使用版本控制来跟踪文件，它也是分布式的，意味着多台计算机存储相关文件。但我的疑问是Git是分布式还是去中心化的？如果它是去中心化的，那么我们为什么需要Github、Gitlab？使用Github和Gitlab使它变得分布式（一主多从节点），对吗？因为我们有一个主节点（像Github这样的）客户端（协作者）依赖它。但Git利用了区块链技术（某种程度上），这让我认为Git是去中心化的，因为所有的区块链技术应用（如比特币、以太坊）都是去中心化的。与比特币不同的是，在Git中节点之间没有点对点的通信，这与区块链的去中心化性质相矛盾。我们需要Github来与其他节点通信，或者如果我们要与其他人合作。请问Git是分布式的还是去中心化的？
2个回答
22
Git既是分布式的，也不是。
它是分布式的...
...意味着任何拥有特定存储库副本的人在理论上都“相等”，和其他拥有相同副本的开发者一样。采用这种方法的主要原因之一是允许任何开发者在无需始终连接到集中式主服务器的情况下继续工作。如果您拥有自己的完整副本，并且它与其他人“相等”，则可以针对其进行开发并稍后进行同步。
它是去中心化的....
...主要是出于以上给出的原因。其中一个核心概念是没有“主”服务器。问题是，在许多情况下（比如大公司的软件工程师），确实需要一个集中式的主服务器。这并不是说Git不适用于这种类型的工作流程（clone --> develop --> commit --> push to central repo），而是它不会强加给你。由于这已成为如此普遍的工作方式，使用GitHub来提供所需结构以启用这种开发周期已成为常态。
它也不是？
由于Git不强制使用任何特定的工作流模型，因此可以得出结论，Git既不是分布式的也不是去中心化的：它在很大程度上超越了这些实现细节，允许用户按照自己的意愿使用它。它包括的功能是抽象和灵活的，以至于它几乎可以适应任何工作流程，但其工作原理留给用户决定。这也是Git对新手来说如此困难的主要原因之一。因此，请记住Git和GitHub不同。Git是一个版本控制工具，而GitHub是一个协作工具，恰好使用Git，并为一个特定类型的开发周期提供了一个非常成熟和熟悉的框架。
此外，git可以与任何主机通信，它并不依赖于GitHub提供集中化，尽管我们经常将其视为这种情况。Git可以使用SSH、HTTP（S）甚至是自己的专有协议来从任何其他系统的repo推送和获取数据，只要用户有能力登录到该主机即可。
那么区块链呢？
Git使用的是与许多常见的区块链实现（例如比特币、以太坊）相同的底层数据结构——哈希树（或默克尔树）。此外，git和区块链都有一些非常相似的需求：它们都希望去中心化和分布式。但是这些特征如何融入两种技术的总体目的却是非常不同的。
在区块链中，去中心化的概念严重依赖于维护共识的需要：对于区块链的完整性而言，节点大多数必须就他们正在构建的分类账内容达成一致是至关重要的。这是因为每个条目都是基于前一个条目的正确性而建立的。没有共识，区块链的整体有用性将变得不明确。
与此相比，Git 虽然也有一些人认为共识在维护仓库完整性方面同样重要，但它并非像工具一样对 Git 的通用实用性如此 intrinsically 重要。同一 repo 的两个克隆可能会大大不同步，但这并不会降低我使用任何一个（或两个）进行版本控制的能力。这也不排除我利用两者的部分内容的能力，只要我不介意做一些手动合并。Git 甚至允许进行一些非常广泛的“树状结构手术”，我可以自由地重写历史，从不同来源（甚至没有共同祖先的来源）中挑选片段并将它们拼接在一起，事后来创造一条纯虚构的事件链。因此，尽管这两种技术有一些表面上的相似之处，还有一些更深层次的相似之处，但它们有着不同的目的和各自独特的设计要求，因此它们彼此之间并不直接可比。
- Z4-tier
9
记得我已经花了一年时间研究同样的问题，我觉得至少要留下一条笔记才能放心离开。毕竟这是一个很好的问题。
考虑到问题中的“分布式”是指有一个中心节点的系统，那么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 的分布式和去中心化使用潜力。
- telamon
1
我对完全去中心化的解决方案一直很感兴趣，最近又开始汇集想法并尝试探索可能性，于是发现了这个。既然你的回答还不算太久远，我想知道你是否有兴趣，并且能否就我和其他人已经开始讨论的问题发表评论，无论是在[cough] github 存储库还是在 Safe Network 论坛主题中：https://safenetforum.org/t/safe-git-ui-discussion/32793?u=happybeing Safe 提供了一个去中心化的平台，因此我的目标是在其之上构建一个 github 替代品。Bingo：去中心化的 git+github。希望能见到你！-happybeing - happybeing
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接
commit（一个加密的数据块）都附加在一个“父”提交（另一个块）上，也称为追加日志。所谓的“区块链”通常指试图达成全球共识的软件。如果问“如何在 P2P 群集上运行 Git？”会更有趣。 - telamon