所以我创建了一个git存储库，在我的工作副本上设置了一些标签和遥控器，然后将存储库推送到我的服务器
git push --mirror my.remote.repository
据说，使用git --mirror推送也会推送我设置的遥控器。
然而，如果我这样做
git clone my.remote.repository
我没有看到我最初创建的遥控器。我是否需要特殊语法来克隆遥控器？镜像实际上不发送遥控器吗？我哪里出错了？
编辑：也许我的工作流程很奇怪：这就是我想要完成的事情。 repo最初是我无法控制的另一个项目（A）的克隆，我将远程重命名为'upstream'。我已经建立了一个新的“主”分支，并打算对我的工作副本进行更改并进行部署。我偶尔会从原始存储库（A）中提取更新（切换到原始的，未修改的分支并从上游拉出）。但是，我正在与其他人合作，所有人都应该能够做到这一点。目标是使用初始存储库（A）中的错误修复更新主分支，并将更改提交到“主”分支。因此，当开发人员克隆存储库时，他们应该继承上游分支，以便他们可以实际执行此操作。简而言之，我正在尝试使用“上游”分支从不同的项目中获取更新。我没有使用子模块来执行此操作，因为'upstream'分支实际上负责存储库中95％的文件，如果没有来自上游的文件，整个项目都没有意义。
答案 0 :(得分：1)
（这不是典型的工作流程，但无论如何我都会尝试回答直接问题......）
git push --mirror确实会将远程跟踪分支推送到远程控制器上的相同名称。但是，当您进行克隆时，默认情况下只会获取refs/heads下的引用，这些引用将映射到refs/remotes/origin/下的远程跟踪分支。您可以使用git clone --mirror进行克隆以从远程获取远程跟踪分支，但该选项意味着--bare。
如果您想要一个具有工作树的存储库，其分支从远程镜像，您可以随时更改配置选项remote.origin.fetch中的refspec以获取每个引用相同的名称，但我再次怀疑真正的问题是你正在使用一个非常不寻常的工作流程。
顺便说一句，即使您使用其中一种技术来更改提取的引用的映射，也不会克隆 remotes 本身，这些是在存储库的git config中定义的 - { {1}}不会克隆来自git clone的任何内容，.git/config被视为包含私人信息。
答案 1 :(得分：0)
克隆 repo 后，只需复制定义远程 URL 的 .git/config 文件：
git clone repo/ repo-clone/ && cp repo/.git/config repo-clone/.git/
其中 repo/ 和 repo-clone/ 是源文件夹和目标文件夹。