hri*_*ham 5 git distributed github decentralized-applications
我知道 git 使用版本控制来跟踪文件。而且它也是分布式的，这意味着不止一台计算机存储相关文件。但我怀疑 git 是分布式的还是去中心化的？如果是去中心化的，那为什么还需要github、gitlab呢？使用 Github 和 Gitlab 使其分布式（一个主多个从节点）对吗？因为，我们有一个 master（如 github），客户（合作者）依赖于它。但是 git 利用了区块链（各种）技术，这让我认为 git 是去中心化的，因为所有区块链技术应用程序，如比特币、以太坊都是去中心化的。与比特币不同，git 中的节点之间没有点对点通信，这与区块链的去中心化性质相矛盾。我们需要 github 来与其他节点通信，或者如果我们要与其他节点协作。
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确实使用与许多常见区块链实现（例如：比特币、以太坊）相同的底层数据结构——称为哈希树（或默克尔树）。更重要的是，git 和区块链都有一些非常相似的要求：它们都寻求去中心化和分布式。但是这些功能如何适应这两种技术的总体目的是完全不同的。
对于区块链，去中心化的概念主要集中在维持共识的需要上：大多数节点同意他们正在构建的分类账内容，这对区块链的完整性至关重要。那是因为每个条目都基于前一个条目的正确性。没有达成共识，区块链的整体用途尚不清楚。
将其与 Git 进行比较，虽然有些人可能会争辩说，共识对于维护存储库的完整性也很重要，但对于 Git 作为工具的一般用途而言，它并不是那么固有。同一个 repo 的两个克隆可能会严重不同步，而不会削弱我使用它们中的一个（或两个）进行版本控制的能力。只要我不介意进行一些手动合并，它也不排除我能够利用两者的一部分。Git 甚至允许进行一些非常广泛的“树手术”，在其中我可以自由地重写历史，从不同来源（甚至没有共同祖先的来源）中挑选片段，事后将它们拼接在一起，以创建一系列纯虚构的事件.
因此，虽然这两种技术有一些表面上的相似之处——有些也有一些更深层次的相似之处——但它们服务于不同的目的，有自己独特的设计要求，因此它们不能直接相互比较。
记住我已经花了一年时间研究同样的问题，我发现至少在不留下便条的情况下很难走开。毕竟这是一个很好的问题。
鉴于问题中的“分布式”是指具有中央节点的系统 - 那么 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 现在是一个区块链（TM）
我目前正在研究“离线优先”软件设计，已经编写了一个纳米大小的无共识离线区块链，我很难写出关于这个主题的报告。
将某事描述为：“......以与 git 相同的方式去中心化”只是不正确。
所以我通过搜索“Git 被认为是去中心化的吗？”来解决这个问题。
好吧，除非有人纠正我，否则我别无选择，只能宣称自己是这方面的专家，我说：
TL; 博士;
Git 本质上既不是去中心化的，也不是分布式的，它是离线的，就像现实生活中的 git 一样，它不在乎。
如果我可以在主题中再添加一段。
以下两个项目说明了 Git“链”可用于托管任意功能，它们都直接挖掘并丰富了 Git 在分布式和去中心化使用方面的潜力。
| 归档时间： |
|
| 查看次数： |
3983 次 |
| 最近记录： |