Git 是分布式还是去中心化？
Is Git distributed or decentralized?
我知道 git 使用版本控制来跟踪文件。而且它也是分布式的，这意味着不止一台计算机存储相关文件。但我怀疑 git 是分布式的还是去中心化的？如果它是去中心化的，那我们为什么需要 github，gitlab？使用 Github 和 Gitlab 使其分布式（一个主节点多个从节点）对吗？因为，我们有一个主控（如 github），客户（合作者）依赖它。但是 git 利用了区块链（某种）技术，这让我觉得 git 是去中心化的，因为所有区块链技术应用程序，如比特币、以太坊都是去中心化的。与比特币不同，git 中的节点内没有点对点通信，这与区块链的去中心化性质相矛盾。我们需要 github 来与其他节点通信，或者如果我们要与其他人协作。请有人告诉我 git 是分布式的还是去中心化的？
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 甚至允许进行一些非常广泛的“树木手术”，我可以在其中自由重写历史，从不同来源（甚至没有共同祖先的来源）中挑选片段并将它们拼接在一起，例如 post 事实上，以创建一连串纯属虚构的事件。
因此，尽管这两种技术有一些表面上的相似之处——有些也有更深层次的相似之处——它们服务于不同的目的并有自己独特的设计要求，因此它们不能直接相互比较。
记得我已经花了一年时间研究同样的东西
问题，我发现很难走开而不至少留下一个
笔记。这毕竟是一个很好的问题。
鉴于问题中的“分布式”指的是具有中央节点的系统 - 那么 Git 与基础设施政治完全无关。
它本身既不集中也不分散，它是一个功能齐全的块链并且离线。
虽然处于离线状态，但它具有分布式和去中心化的潜力
但直到 用户 推或拉 to/from 遥控器。
Git 还支持多个遥控器，因此以集中方式使用 git 不会限制它的分散功能。
我们将 Git 与中央集线器一起使用的原因是因为分散式替代方案提供与云平台类似的成本效益和便利性 - 尚不存在 .
但是有有效的分布式遥控器：
hypergit 创建一个 git-remote 指向
到一对多（单个作者）p2p-swarm，使来自中央节点的提交无服务器 分布式.
如果您和几个朋友决定创建自己的个人 hypergit 端点并同意在进行推送之前始终尝试从每个人的端点获取数据；
那么你们之间就有了一个完全去中心化的解决方案。
然而，您很快就会注意到，此模型的扩展很笨拙，并且同步复杂性随着添加到您的组中的参与者数量呈指数级增长。
为了澄清问题：在上面的模型中，我们引入了一个简单的全局时间锁来降低合并冲突的风险——因为 Git 没有“自动冲突解决策略”，默认行为是发出警报并让用户手动更正任何合并冲突。
但是，如果您和您的朋友在不知不觉中解决了相同的合并冲突，甚至可能设法产生不同的结果，会发生什么？
在中心化系统中，这是一场有点不公平但又很熟悉的竞赛——
第一个设法将无冲突提交推送到 origin/master 的人
当天第一个回家。
但是当有多个远程源时你会怎么做？
或者作为 git-swarm 中的初级人员，其中包含相互冲突的合并冲突解决方案，
我怎么知道从哪个点拉？
我可能会站起来问：
"I see conflicts everywhere, who of you has the latest non-conflicting state?"
经过片刻的讨论，一些手指应该指向一个单独的遥控器。
这意味着，团队就使用谁的 master 分支达成了共识。
在一个完全去中心化的系统中打扰你的邻居所花费的时间
并达成共识，有足够的时间让新提交在冲突的分支上结束，从而产生一组需要解决的全新冲突。
因此，为了解决这个问题，我们应用了一些群体智能，并为每个对等节点配备了“自动冲突解决策略”
假设：
The branch that contains the most recent commits by seniority should be considered canon.
（忽略没有单个时钟显示同一时间的事实）
我们可以聚合 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，而不必打扰它的邻居。
通过自主解决冲突，我们在理论上已经解决了
以前的扩展问题，现在可以丢弃所有单独的群端点，支持一个多对多稀疏连接的群，其中根据去中心化中的策略转发、合并和丢弃提交方式。
Git is now a Blockchain(TM)
...
我目前正在研究“离线优先”软件设计，
写了一篇 nano-sized consensus-free offline blockchain 我在尝试写一篇关于这个主题的报告时遇到了困难。
将某事描述为：“...以与 git 相同的方式去中心化”只是
坐错了。
所以我通过搜索“Git 是否被认为是去中心化的？”找到了这个问题
好吧，除非有人纠正我，否则我别无选择，只能宣称自己是这方面的专家，
我说：
TL;DR;
Git is inherently neither decentralized nor distributed it is offline and just like a real life git, it doesn't care.
如果我可以在主题中再添加一段。
下面两个项目说明可以使用Git“链”
为了承载任意功能，它们都直接利用并丰富了 Git 分布式和去中心化使用的潜力。
我知道 git 使用版本控制来跟踪文件。而且它也是分布式的，这意味着不止一台计算机存储相关文件。但我怀疑 git 是分布式的还是去中心化的？如果它是去中心化的，那我们为什么需要 github，gitlab？使用 Github 和 Gitlab 使其分布式（一个主节点多个从节点）对吗？因为，我们有一个主控（如 github），客户（合作者）依赖它。但是 git 利用了区块链（某种）技术，这让我觉得 git 是去中心化的，因为所有区块链技术应用程序，如比特币、以太坊都是去中心化的。与比特币不同，git 中的节点内没有点对点通信，这与区块链的去中心化性质相矛盾。我们需要 github 来与其他节点通信，或者如果我们要与其他人协作。请有人告诉我 git 是分布式的还是去中心化的？
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 甚至允许进行一些非常广泛的“树木手术”，我可以在其中自由重写历史，从不同来源（甚至没有共同祖先的来源）中挑选片段并将它们拼接在一起，例如 post 事实上，以创建一连串纯属虚构的事件。
因此，尽管这两种技术有一些表面上的相似之处——有些也有更深层次的相似之处——它们服务于不同的目的并有自己独特的设计要求，因此它们不能直接相互比较。
记得我已经花了一年时间研究同样的东西 问题，我发现很难走开而不至少留下一个 笔记。这毕竟是一个很好的问题。
鉴于问题中的“分布式”指的是具有中央节点的系统 - 那么 Git 与基础设施政治完全无关。
它本身既不集中也不分散，它是一个功能齐全的块链并且离线。
虽然处于离线状态，但它具有分布式和去中心化的潜力 但直到 用户 推或拉 to/from 遥控器。 Git 还支持多个遥控器，因此以集中方式使用 git 不会限制它的分散功能。
我们将 Git 与中央集线器一起使用的原因是因为分散式替代方案提供与云平台类似的成本效益和便利性 - 尚不存在 .
但是有有效的分布式遥控器：
hypergit 创建一个 git-remote 指向 到一对多（单个作者）p2p-swarm，使来自中央节点的提交无服务器 分布式.
如果您和几个朋友决定创建自己的个人 hypergit 端点并同意在进行推送之前始终尝试从每个人的端点获取数据； 那么你们之间就有了一个完全去中心化的解决方案。 然而，您很快就会注意到，此模型的扩展很笨拙，并且同步复杂性随着添加到您的组中的参与者数量呈指数级增长。
为了澄清问题：在上面的模型中，我们引入了一个简单的全局时间锁来降低合并冲突的风险——因为 Git 没有“自动冲突解决策略”，默认行为是发出警报并让用户手动更正任何合并冲突。 但是，如果您和您的朋友在不知不觉中解决了相同的合并冲突，甚至可能设法产生不同的结果，会发生什么？
在中心化系统中，这是一场有点不公平但又很熟悉的竞赛——
第一个设法将无冲突提交推送到 origin/master 的人
当天第一个回家。
但是当有多个远程源时你会怎么做？
或者作为 git-swarm 中的初级人员，其中包含相互冲突的合并冲突解决方案， 我怎么知道从哪个点拉？ 我可能会站起来问：
"I see conflicts everywhere, who of you has the latest non-conflicting state?"
经过片刻的讨论，一些手指应该指向一个单独的遥控器。 这意味着，团队就使用谁的 master 分支达成了共识。
在一个完全去中心化的系统中打扰你的邻居所花费的时间 并达成共识，有足够的时间让新提交在冲突的分支上结束，从而产生一组需要解决的全新冲突。
因此，为了解决这个问题，我们应用了一些群体智能，并为每个对等节点配备了“自动冲突解决策略”
假设：
The branch that contains the most recent commits by seniority should be considered canon.
（忽略没有单个时钟显示同一时间的事实） 我们可以聚合 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，而不必打扰它的邻居。
通过自主解决冲突，我们在理论上已经解决了 以前的扩展问题，现在可以丢弃所有单独的群端点，支持一个多对多稀疏连接的群，其中根据去中心化中的策略转发、合并和丢弃提交方式。
Git is now a Blockchain(TM)
...
我目前正在研究“离线优先”软件设计， 写了一篇 nano-sized consensus-free offline blockchain 我在尝试写一篇关于这个主题的报告时遇到了困难。
将某事描述为：“...以与 git 相同的方式去中心化”只是 坐错了。
所以我通过搜索“Git 是否被认为是去中心化的？”找到了这个问题
好吧，除非有人纠正我，否则我别无选择，只能宣称自己是这方面的专家， 我说：
TL;DR;
Git is inherently neither decentralized nor distributed it is offline and just like a real life git, it doesn't care.
如果我可以在主题中再添加一段。
下面两个项目说明可以使用Git“链” 为了承载任意功能，它们都直接利用并丰富了 Git 分布式和去中心化使用的潜力。