git clone --mirror和git clone --bare之间的区别是什么

Question

git clone帮助页面有这样的说法--mirror:

设置远程存储库的镜像.这意味着--bare.

但是没有详细说明--mirror克隆与克隆的不同之处--bare.

Answer 1

不同之处在于,使用时--mirror,所有引用都按原样复制.这意味着一切:远程跟踪分支,备注,引用/原件/*(来自filter-branch的备份).克隆的回购拥有一切.它也设置为远程更新将从原点重新获取所有内容(覆盖复制的引用).这个想法实际上是为了镜像存储库,以获得一个完整的副本,以便您可以在多个位置托管您的中央存储库,或者备份它.想想只是直接复制回购,除了更优雅的git方式.

新文档几乎说明了这一切:

--mirror

设置源存储库的镜像.这意味着--bare.相比之下--bare,--mirror不仅将源的本地分支映射到目标的本地分支,它还映射所有引用(包括远程分支,注释等)并设置refspec配置,以便所有这些引用都被git remote update目标存储库中的a覆盖.

我的原始答案还注意到裸克隆和普通(非裸)克隆之间的差异 - 非裸克隆设置远程跟踪分支,仅创建本地分支HEAD,而裸克隆直接复制分支.

假设起源有几个分支(master (HEAD),next,pu和maint),一些标签(v1,v2,v3),一些远程分支机构(devA/master,devB/master),以及其他一些裁判(refs/foo/bar,refs/foo/baz,这可能是笔记,储物箱,其他开发者的命名空间,谁知道).

• git clone origin-url(非裸):您将得到所有复制的标签,一个本地分支master (HEAD)追踪远程分支origin/master和远程分支origin/next,origin/pu和origin/maint.设置了跟踪分支,这样如果你做了类似的事情git fetch origin,它们就会像你期望的那样被提取.任何远程分支(在克隆的远程中)和其他引用都被完全忽略.

• git clone --bare origin-url:您将获得全部复制的标签,地方分支机构master (HEAD),next,pu,和maint,没有远程跟踪分支.也就是说,所有分支都按原样复制,并且它设置为完全独立,不期望再次获取.任何远程分支(在克隆的远程中)和其他引用都被完全忽略.

• git clone --mirror origin-url:这些引用中的每一个都将按原样复制.你会得到所有的标签,地方分支机构master (HEAD),next,pu,和maint,远程分支机构devA/master和devB/master其他裁判refs/foo/bar和refs/foo/baz.一切都与克隆的遥控器完全一样.设置远程跟踪,以便在运行时,git remote update所有引用都将从原点覆盖,就像您刚删除镜像并重新克隆它一样.正如文档最初所说,它是一面镜子.它应该是功能相同的副本,可与原始版本互换.

Answer 2

$ git clone --mirror $URL

是一个简称

$ git clone --bare $URL
$ (cd $(basename $URL) && git remote add --mirror=fetch origin $URL)

(直接从这里复制)

当前的man-page如何表达:

相比之下--bare,--mirror不仅将源的本地分支映射到目标的本地分支,它还映射所有引用(包括远程分支,注释等)并设置refspec配置,以便所有这些引用都被git remote update目标存储库中的a覆盖.

Answer 3

我今天使用git-2.0.0进行的测试表明--mirror选项不会复制挂钩,配置文件,描述文件,信息/排除文件,至少在我的测试用例中有一些参考(我不喜欢)理解.)我不会称之为"功能相同的副本,可以与原始副本互换".

-bash-3.2$ git --version
git version 2.0.0
-bash-3.2$ git clone --mirror /git/hooks
Cloning into bare repository 'hooks.git'...
done.

-bash-3.2$ diff --brief -r /git/hooks.git hooks.git
Files /git/hooks.git/config and hooks.git/config differ
Files /git/hooks.git/description and hooks.git/description differ
...
Only in hooks.git/hooks: applypatch-msg.sample
...
Only in /git/hooks.git/hooks: post-receive
...
Files /git/hooks.git/info/exclude and hooks.git/info/exclude differ
...
Files /git/hooks.git/packed-refs and hooks.git/packed-refs differ
Only in /git/hooks.git/refs/heads: fake_branch
Only in /git/hooks.git/refs/heads: master
Only in /git/hooks.git/refs: meta

Answer 4

与 和不同git clone，git clone --mirror两者git clone --bare都是裸露的存储库。它们之间的区别在config文件中。

\n

git clone\ 的配置文件如下所示：

\n

[remote "origin"]\n    url = https://github.com/example\n    fetch = +refs/heads/*:refs/remotes/origin/*\n

\n

git clone --bare\ 的配置文件如下所示：

\n

[remote "origin"]\n    url = https://github.com/example\n

\n

git clone --mirror\ 的配置文件如下所示：

\n

[remote "origin"]\n    url = https://github.com/example\n    fetch = +refs/*:refs/*\n    mirror = true\n

\n

因此，我们看到用于获取的refspec的主要区别

\n

\n

refspec 的格式首先是一个可选的+，然后是<src>:<dst>，其中<src>是远程端引用的模式，并且<dst>是在本地跟踪这些引用的位置。告诉+Git 更新引用，即使它不是快进的。

\n

\n

如果git clone是通过命令自动写入的git remote add origin，Git 会获取服务器上的所有引用refs/heads/并将它们写入refs/remotes/origin/本地。

\n

在 的情况下git clone --bare，没有可用于获取的引用规范。

\n

在 的情况下git clone --mirror，用于获取的 refspec 看起来像fetch = +refs/*:refs/*。这意味着，tags, remotes, replace（位于refs目录下）也heads将被获取。请注意，默认情况下git clone仅 fetchheads。

\n

注 1： git clone --mirror和git clone --bare --mirror是等效的。

\n

注2：也存在差异packed-refs。refs/heads/因为它记录的信息与、refs/tags/、 和朋友以更有效的方式记录相同的信息。

\n

Answer 5

关于复制存储库的GitHub文档中的细致解释:

与裸克隆一样,镜像克隆包括所有远程分支和标记,但每次获取时都会覆盖所有本地引用,因此它将始终与原始存储库相同.

Answer 6

克隆从远程复制引用并将它们填充到名为"这些是远程具有的引用"的子目录中.

镜像从远程复制refs并将它们放入自己的顶层 - 它将自己的refs替换为远程的refs.

这意味着当有人从镜像中拉出并将镜像的refs填充到其子目录中时,它们将获得与原始镜像相同的引用.从最新镜像获取的结果与直接从初始repo获取的结果相同.

Answer 7

我添加了一张图片,显示config了镜像和裸镜之间的区别. 左边是裸露的,右边是镜子.您可以清楚,镜像的配置文件有fetch密钥,这意味着您可以通过git remote update或更新它git fetch --all

Answer 8

$ git clone --bare https://github.com/example

此命令将使新的“ example”目录本身成为 $GIT_DIR （而不是example/.git）。并且远程的分支头直接复制到相应的本地分支头，无需映射。使用此选项时，既不会创建远程跟踪分支，也不会创建相关的配置变量。

$ git clone --mirror https://github.com/example

与裸克隆一样，镜像克隆包含所有远程分支和标签，但每次获取时所有本地引用（包括远程跟踪分支、注释等）都将被覆盖，因此它将始终与原始存储库相同。