Git 我如何拉到一个光秃秃的存储库？

我有一个“主”裸存储库和一个“个人”裸存储库。我想将更改表单“main”更新为“personal”，因此我运行：

$ git pull
fatal: /home/gimenero/applib/git/libexec/git-core/git-pull cannot be used without a working tree.

---

如何提取推送到“main”的更改？

git pull执行

提取

，然后执行

合并

，如果没有工作树，则无法进行合并。（如果出现合并冲突，将无处解决。）

相反，你可以直接去拿。假设您的主存储库配置为个人存储库上的远程调用源：

$ git fetch origin master:master

请注意，只有当个人存储库的主分支镜像主存储库的主分支时，此操作才会成功。否则，Git将拒绝非快进提取。

更新为：

$ git fetch origin +refs/heads/*:refs/heads/* --prune

这有什么用？ 第一个旁白：当我们提到一个名为“xyz”的分支时，git实际上将其命名为

refs/heads/xyz

。但是你可以简略地键入“

xyz

”，否则它会很疯狂。（顺便提一下，标记是

refs/tags/xyz

）Plain

xyz

是不明确的，因为它可能是分支、标记或提交散列的前N个字母<另一方面，code>refs/heads/xyz明确表示分支

因此，即使您可以键入

git-fetch-origin-foo:bar

以获取存储库中名为

bar

的

foo

分支，您也可以更明确地键入

git-fetch-origin-refs/heads/foo:refs/heads/bar来执行相同的操作。（虽然如果
foo
实际上是一个标记而不是一个分支，但后者将失败，因为它们的
refs/heads/foo
不存在。明确性ftw。）

git fetch origin refs/heads/*：refs/heads/*
表示其所有分支都属于我们。运行该命令时，就像将
*
部分替换为每个分支的分支名称一样。i、 e.
git获取原点refs/heads/abc:refs/heads/abc refs/heads/def:refs/heads/def…
（假设它们有名为
abc
和
def
的分支）

--prune
选项意味着我们存储库中与
refs/heads/*
匹配但不存在于其存储库中的任何分支都将被删除

最后，
+
前缀允许非快进回迁。如果没有它，任何需要强制更新的分支更新都将被拒绝

总而言之，最终结果是存储库中的分支最终看起来与它们的分支完全相同

以下是一个示例输出：

这个例子告诉我们他们有分支
foo
，
abc
，
def
，而我们有一个额外的分支：
bar
请注意，
--prune
删除了
条
，并强制更新
+
前缀允许的
def

如果禁用了
+
和
--prune
，则会发生以下情况：

 * [new branch]            foo        -> foo
   4812558a5f..a6aeec6517  abc        -> abc
 ! [rejected]              def        -> def  (non-fast-forward)

最后一件事：
将顶部的命令与以下命令进行比较：

$ git fetch origin +refs/heads/*:refs/remotes/origin/* +refs/tags/*:refs/tags/* [--prune]

当我们键入
git fetch origin[--prune]
时，基本上就是这样
 我想你指的是git fetch origin master:master是的，我以为是fetch做的，但当我写到：“git fetch”时，它说：“From/home/rater/gitRepo/src*branch HEAD->fetch_HEAD”。那个“头->取头”把我弄糊涂了。这是什么意思？（它看起来像是在一个非裸回购协议中获取一个FETCH_HEAD，用于以后的合并）当我写到：“git FETCH origin master:master”时，它什么也没说，我不明白。如果我获取本地主分支指针，它将不会指向远程主指针的同一个提交。它怎么能快速前进呢，难道这不应该只发生在拉动过程中吗？我原以为
git-fetch--all
可以工作，但它没有给出期望的结果（即，如果你在裸“个人”回购中执行
git-fetch--all
，然后将cd放入非裸“个人”回购中）回购并执行一个
git pull
master repo中的任何更改都不会被提取）上面的答案可能比另一个更强大、更灵活，但它不可见。稍加解释，这个答案可能会有趣得多。据我所知，这个命令与git
push--mirror
相反，这很危险（即使在发生冲突的情况下也会替换，在目标端删除任何不在发送方的内容）。
$ git fetch origin +refs/heads/*:refs/remotes/origin/* +refs/tags/*:refs/tags/* [--prune]