这看起来似乎是一个愚蠢的问题，但是如何在没有服务器的情况下设置工作的drectory？企业如何保留回购的安全备份副本？
我认为必须有一个中央回购......但那么它究竟是如何“分配”的呢？我一直认为服务器 - 客户端（SVN）与对等（GIT）的区别，但我不相信这是正确的，除非像GIT这样的工具依赖于洪流式技术吗？
答案 0 :(得分：9)
分布式版本控制系统真的没有集中存储库吗？
没有强制中央存储库 - 它只是按惯例。大多数项目做都有一个中央存储库，但每个存储库在它们具有完整历史记录的意义上是相同的，并且可以在彼此之间推送和拉取补丁。
考虑它的一种方法是集中式VCS在星型拓扑中修复：一个中央集线器充当具有完整存储库的服务器，其中一个或多个客户端挂起。客户通常只拥有最新清理结账的副本和有限的历史记录（如果有）。因此大多数操作都需要往返服务器。通过在一个存储库中创建分支来实现分支。
在分布式VCS中，网络拓扑没有限制。理论上你可以有任何你喜欢的形状。您可以为每个团队或子项目创建单独的存储库，并进行阶段提交。您可以拥有一个稳定的存储库和一个不稳定的存储库，以及许多功能分支，等等。并且没有客户端/服务器区别 - 所有节点都是相同的。每个存储库都是独立且完整的，可以推送和/或拉取任何其他存储库的更改。首先，您可以克隆现有存储库（使自己的副本可以使用），然后开始进行更改。一旦你第一次提交，你实际上有一个分支。幸运的是，通常很容易在完成后合并您的更改。
但正常发生的事情是，您有一个位于中央服务器上的存储库，这使人们更容易上手，并跟踪最新更改的位置。
如何在没有服务器的情况下设置工作的drectory？
您的存储库必须从源树开始。所以总有一个第一个存储库，带有最初的一系列签到。假设你想在Murky上工作。您将克隆存储库，它为您提供了一个完整的存储库，包含所有历史记录和签入。您进行了一些更改（从而创建了一个分支），当您完成后，您可以将更改推回到合并的位置。两个系统都充当同伴，他们在彼此之间推送和拉动变更集。
Mercurial和Git都将存储库保存在一个隐藏的子目录中，因此一个目录树包含您的工作副本（可以是您喜欢的任何状态）和repo本身。
企业如何保留回购的安全备份副本？
如上所述，您只需拥有一个指定的主存储库，其中包含所有最新的合并更改，并将其备份为其他任何内容。您甚至可以拥有多个备份存储库，或者在物理上独立的盒子上具有自动克隆。在某些方面，备份更容易。
我认为必须有一个中央回购......但那么它究竟是如何“分配”的呢？我一直认为服务器 - 客户端（SVN）与对等（GIT）的区别，但我不相信这是正确的，除非像GIT这样的工具依赖于洪流式技术吗？
在不同客户端具有不同部分（如对等文件共享）的意义上，它不是分布式的。这与集中模型形成鲜明对比。
所有DVCS存储库都是一等公民。它成为如何安排它们的社会或管理问题，而不是技术问题。
答案 1 :(得分：7)
Re：'洪流式技术' - 令人困惑的是2个问题，一个是网络拓扑（点对点与服务器/客户端），另一个是服务器权限。这是可以理解的，因为术语几乎相同。但是，对网络连接模型提出任何要求的分布式源代码控制一无所知 - 如果您愿意，可以通过电子邮件分发变更集。分布式版本控制的重要一点是每个人基本上都运行自己的服务器并合并来自其他服务器的更改。当然，您需要能够从某个地方获取初始克隆，以及您如何知道“某处”的位置超出了系统本身的范围。没有“跟踪器”程序或任何东西 - 通常有人在某个地方有一个公共存储库，地址是在网站上发布的。但是一旦你克隆了它，你的副本就是一个完整的副本，能够成为别人克隆的基础。
答案 2 :(得分：6)
这里有一个重要的区别：是否有技术中央服务器，或者按照惯例有一个。
技术上 git存储库的所有克隆都是等效的。所有这些都允许更改，签到，分支，相互合并。没有任何单一的存储库以某种方式比其他存储库更“真实”。
按社会惯例大多数使用git的项目都有一个中央存储库，该存储库被认为是权威存储库，代表项目的官方状态。
将其与更传统的VCS（如SVN）进行比较：此处中央存储库技术上与每个开发人员可能具有的本地结帐非常不同。本地签出只能执行与中央存储库相关的VCS操作。没有中央存储库，开发人员就无法提交。
答案 3 :(得分：5)
使用分布式版本控制，您可以将整个历史记录（整个存储库）的完整副本作为本地（签出）副本的一部分嵌入。
在添加中，大多数项目都会有一些中央存储库，也拥有所有内容的副本。这意味着在某些时候您需要将您的更改从本地存储库推送到中央存储库。但这也意味着你可以在本地工作到你的内心，然后只推动你想推的变化，你只需要在准备好时推它们。
例如，看一下Linux内核：很多人会从某处查看“克隆”内核树。它可能是Linus的树，或者它可能是在kernel.org或互联网上漂浮的其他树之一。但Linus的树存在于kernel.org和（可能）也存在于Linus的计算机上（以及从那里撤出的任何其他计算机）。
Joel的最新blog post描述了DVCS最佳的优势（以及与Subversion等系统的主要区别）：
当您管理更改而不是管理版本时，合并效果会更好，因此，您可以在组织目标需要的任何时候进行分支，因为合并将是一件小事。
所以你把一张树的副本放在某个中央服务器的某个地方，其他人可以从那里取出（或者在你的私人服务器上，这样你就有了备份）。当你想要它时，你会把一些东西推到那里。然后，如果有人想要副本，他们可以从那里克隆。
答案 4 :(得分：2)
从技术上讲，DVCS不需要集中存储库。
在现实生活中，应用程序（例如Linux内核）必须在交付之前从单个商定的源集合构建。
通过这种方式，DVCS不会施加任何源管理策略，并将此类决策留给项目经理。
答案 5 :(得分：1)
“点对点”比喻实际上是指来自另一个回购的 how you get changes 。
由于您可以从任何其他“对等”存储库（共享相同的第一次提交的存储库）获取，因此您可以将其视为peer-to-peer model，因为：
与只有服务器供应和客户消费的传统客户端 - 服务器模型相比，同行是资源的供应商和消费者。
答案 6 :(得分：0)
从技术上讲，您不需要中央服务器：您可以与同行交换提交，就是这样。
逻辑上（只看一下github.com）总会有（至少）一个中央存储库，某种你需要依赖的“主副本”。我想在Linux内核上，Linus的回购是主要的，最终接受了更改，不是吗？
我认为对于拥抱DVCS的公司来说尤其如此：他们不会依赖开发人员的“副本”而是集中式的，但显然，可能不仅仅是一个副本（这对于避免灾难是非常好的）也:-P，并且相当自然地发生在DVCS上）