这个问题是关于透明复制的，我怀疑还没有答案，因为人们可能会挂在透明上。我现在暂时保留透明性以专注于复制。稍后，我将讨论（或精妙的）透明度，实际上，我实际上并不认为在DVCS中那么重要。
首先，让我简要介绍一下DVCS中存储库工作方式的几个关键点。（我最熟悉Mercurial，因此我将使用它作为示例，但我相信我所说的一切也适用于git。）
答：在DVCS中，任何克隆都包含与原始文件相同的文件内容和历史记录。
只要使您的存储库保持正确同步，这意味着您可以使用普通DVCS更改传播操作（克隆，推入，拉入）和普通存储库来构建复制系统。
B.不必将新更改传播到其来源。
特别是，如果我要从某个特定的存储库中获取更改，并添加自己的一些更改，则我的更改不必回到该特定的存储库中。他们可以去其他地方。我将在下面显示的示例中使它的实用程序变得清晰。
C.更改可以通过推或拉传播。
在集中式系统中，新变更几乎只能（在我看来）被推送到仓库中。在DVCS中，可以设置各种变更传播拓扑，其中一些仅涉及拉动。这为设置提供了更大的灵活性。
例子
为了便于讨论，我们假设您的分布式团队使用duke.de，duke.us，duke.cn和duke.mx域中的系统，此外，duke.de是我们想要拥有“祝福”存储库的位置。考虑到这些假设，考虑到上面的三个DVCS关键点，让我列出您可以设置的各种不同拓扑的示例。
0.集中式推送模型
在hg.duke.de上有一个存储库，所有位置的开发人员都可以从此处克隆并提取并在此处进行更改。这可能对德国人有用，但对世界其他地区的人来说可能是个问题。所有克隆，拉动和推送操作都将穿越慢速的远程网络链接。就像集中式系统一样，这使用的是DVCS。这是您要解决的问题。
1.集中复制推送
在hg.duke.de上有祝福的仓库，在hg.duke.cn，hg.duke.mx和hg.duke.us上有副本。开发人员从其本地副本中克隆并将更改推送到hg.duke.de。每当hg.duke.de中出现新更改时，就会运行一个钩子，将其传播到副本。副本是只读的，因此永远不会有任何合并或冲突。
例如，如果我是墨西哥的开发人员，我将从hg.duke.mx克隆，但将更改推送到hg.duke.de。如果在我可以推送更改之前将其他更改推送到hg.duke.de中，我的推送将被阻止。其他更改将被复制到hg.duke.mx，因此我将在本地将这些更改拉出，合并，然后尝试再次推送到hg.duke.de。
这应该提供一些优势，因为大型克隆操作都在本地完成。推送到另一个位置的中央仓库可能并不算太糟，因为更改相对很少地被推送，因此增量更改通常很小。（特别是Mercurial会发送压缩的差异，而不是整个文件及其历史记录。）
在Mercurial中，您可以通过在.hg/hgrc文件中放置以下内容来设置本地存储库，以从一个位置提取并推送到另一位置：
[paths]
default = ssh://hg.duke.mx
default-push = ssh://hg.duke.de
2.简单拉模型
继续hg.duke.de作为有福的仓库，其他作为副本，我们可以通过pull而不是push传播更改。开发人员照常克隆并从其本地副本中提取。更改准备就绪后，开发人员将向某个中央服务提交拉取请求，该请求将从开发人员的存储库中拉至hg.duke.de。需要为合并制定政策。例如，如果存在合并冲突，则该请求可能会被拒绝，从而要求开发人员从本地副本中拉出，合并并重新提交拉出请求。
这种方法的优点是在传播更改时不会让开发人员等待。当然，开发人员仍然必须等待请求请求被执行，但是至少他或她可以在此期间进行其他更改。
变化
有很多可以应用的变体。
提交拉取请求是进行代码审查的最佳时机。从某种意义上说，这些更改已发布，每个人都可以使用，但尚未将其集成到有福的仓库中。
拉取请求可以手动执行，也可以通过某些自动化系统执行。处理拉取请求可能不会将更改直接合并到有福的仓库中，而是合并到临时的暂存区域中，在此区域中完成构建和测试周期。只有通过所有测试后，变更集才能集成到有福的仓库中。
那些对推送模型比较满意的人可能希望在每个位置以及副本（例如hg-stage.duke.mx，hg-stage.duke.cn等）旁边建立本地分段存储。这需要更多的工作，但是，由于开发人员不仅必须与其他本地更改合并，而且还必须由某人负责将分阶段存储库中的更改合并到有福的存储库中。不过，这可以在适当的情况下工作，并且可以借助自动化来辅助。
“透明度”
现在到透明复制的问题。
考虑到上述情况，我真的看不到需要透明复制。所有存储库对所有人都是可见的，并且有从本地复制库中进行拉/克隆并推送到有福存储库或本地暂存区的约定。
如果需要透明性，可以让人们根据他们的位置来设置DNS搜索域。本地副本和分段存储库将简称为“ hg”和“ hg-stage”，DNS设置会将它们解析为hg.duke.cn和hg-stage.duke.cn（适用于中国的开发人员），并相应地用于开发人员在其他位置。但这有点不可思议，并且可能会造成混淆，而且我真的认为它不会增加太多。
我希望这回答了你的问题。我对答复采取了多种自由，但在我看来，可以通过使用上面描述的技术来纠正您的情况。