我知道 git 使用版本控制来跟踪文件。而且它也是分布式的，这意味着不止一台计算机存储相关文件。但我的疑问是 git 是分布式的还是去中心化的？如果是去中心化的，那我们为什么需要github、gitlab？使用 Github 和 Gitlab 使其分布式（一个主多个从节点）对吗？因为，我们有一个主服务器（比如 github），客户（合作者）依赖它。但是 git 利用了区块链技术，这让我觉得 git 是去中心化的，因为比特币、以太坊等所有区块链技术应用都是去中心化的。与比特币不同的是，git 中的节点内没有点对点通信，这与区块链的去中心化性质相矛盾。我们需要 github 与其他节点进行通信，或者如果我们要与其他节点协作。
问问题
5456 次
2 回答
11
Git 两者兼而有之（也不是）。
它是分布式...
...从某种意义上说，任何拥有特定存储库克隆的人在理论上“等于”任何其他拥有相同存储库克隆的开发人员。使用这种方法的主要原因之一是允许任何开发人员继续他们的工作，而无需始终连接到集中式主服务器。如果您有自己的完整副本，并且它与任何其他副本“相同”，您可以针对它进行开发并稍后同步。
它是去中心化的......
...主要出于上述相同的原因。核心概念之一是没有“主”服务器。这样做的问题是，在许多情况下（比如大公司的软件工程师），确实需要一个集中的主控。并不是说 Git 不适合这种类型的工作流程 ( clone --> develop --> commit --> push to central repo)，而是它不会强加给您。由于这是一种无处不在的工作方式，因此在 Git 之上使用 GitHub 来提供所需的结构以实现这种类型的开发周期已成为常态。
两者都不是？
因为它不强迫您使用任何特定的工作流模型，所以得出 Git 既不是分布式也不是去中心化的结论也许也是合理的：它在很大程度上超越了这些实现细节，允许用户随心所欲地使用它。它包括抽象和灵活的功能，以至于它几乎可以适应任何工作流程，但它的工作方式留给用户决定。这也是 Git 对新手来说如此难学的主要原因之一。
所以只要记住 Git 和 GitHub 是不一样的。Git 是一个版本控制工具，而 GitHub 是一个恰好使用 Git 的协作工具，并为特定类型的开发周期提供了一个框架，该框架非常成熟并且为许多人所熟悉。
此外，git 可以与任何主机通信，它绝不依赖 GitHub 来提供集中化，即使我们经常将其视为这种情况。Git 可以使用 SSH、HTTP(S) 甚至它自己的专有协议从任何其他系统上的存储库中推送和获取数据，前提是用户能够登录到该主机。
区块链呢？
Git确实使用与许多常见的区块链实现（例如：比特币、以太坊）相同的底层数据结构——称为哈希树（或 Merkle 树）。更重要的是，git 和区块链都有一些非常相似的要求：它们都寻求去中心化和分布式。但是这些功能如何适应这两种技术的总体目的却是完全不同的。
对于区块链，去中心化的概念主要集中在维持共识的需要上：大多数节点同意他们正在构建的分类账的内容对于区块链的完整性至关重要。这是因为每个条目都基于前一个条目的正确性。如果没有达成共识，区块链的整体用途尚不清楚。
将其与 Git 进行比较，虽然有些人可能会争辩说，共识对于维护存储库的完整性也很重要，但对于 Git 作为工具的一般有用性而言，它并不是那么固有。同一个 repo 的两个克隆可能会严重不同步，而不会降低我使用它们中的任何一个（或两者）进行版本控制的能力。只要我不介意进行一些手动合并，它也不排除我利用两者的一部分的能力。Git 甚至允许进行一些非常广泛的“树手术”，在其中我可以自由地重写历史，从不同的来源（甚至没有共同祖先的来源）中挑选片段，并事后将它们拼接在一起，以创建一个纯虚构的事件链.
因此，虽然这两种技术有一些表面上的相似之处——也有一些更深层次的相似之处——但它们服务于不同的目的并有自己独特的设计要求，因此它们之间没有直接的可比性。
于 2019-12-28T10:02:44.033 回答
5
想起我已经花了一年的时间研究同一个问题，我发现很难不留条子就走开。这毕竟是一个很好的问题。
鉴于问题中的“分布式”指的是具有中央节点的系统 - 那么 Git 对基础设施政治非常不可知论。
它本身既不是中心化的也不是去中心化的，它是一个功能齐全的区块链，它是离线的。
虽然处于离线状态，但它具有分布式和去中心化的潜力，但在用户向/从远程推送或拉取之前，它都不是。Git 还支持多个遥控器，因此以集中方式使用 git 不会限制它的分散功能。
我们将 Git 与中央集线器一起使用的原因是，尚不存在提供与云平台类似的成本效益和便利性的去中心化替代方案。
然而，有有效的分布式遥控器：
hypergit创建一个 git-remote 指向一个一对多（单一作者）p2p-swarm，使来自中央节点的提交无服务器分布式。
如果您和几个朋友决定创建自己的个人 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 端点，转而使用一个多对多稀疏连接的 swarm，其中根据策略以分散的方式转发、合并和丢弃提交。
Git 现在是 Blockchain(TM)
...
我目前正在研究“离线优先”软件设计，已经编写了一个纳米级的无共识离线区块链，但我非常难于写一篇关于这个主题的报告。
将某事描述为：“......以与 git 相同的方式去中心化”只是不正确。
所以我通过搜索“Git 被认为是去中心化的吗？”来解决这个问题。
好吧，除非有人纠正我，否则我别无选择，只能宣称自己是这方面的专家，我说：
TL;博士;
Git 本质上既不是去中心化的也不是分布式的，它是离线的，就像现实生活中的 git一样，它不在乎。
如果我可以在主题上再添加一段。
以下两个项目说明了 Git“链”可用于承载任意功能，它们都直接挖掘并丰富了 Git 在分布式和去中心化使用方面的潜力。
于 2020-05-26T21:33:47.133 回答