使用单个命令获取远程服务器中的所有更改

Question

我有不添加远程git-hub服务器的习惯，而是直接进行提取

当我做

git fetch url //does not fetch all the changes from remote
git remote add origin url 
git fetch origin //fetches all the changes from remote

是否有任何命令可以使用单个命令获取远程中的所有更改。 获取网址和获取来源之间也存在差异。

Answer 1

这是因为中的Refspec当你做一个补充git remote add 。

remote.origin.url=git@github.com:<username>/<reponame>
remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*

该refspec将指示git获取什么以及在哪里：

• 它获取所有的heads ，
• 将它们放入您的本地克隆存储库中的remotes/origin/

（正如我在此答案中也提到的）

当您直接使用url时，本地配置中没有任何说明来指示Git要获取什么。

Answer 2

养成使用诸如origin或github类的远程名称的习惯可能会好得多，但是我自己对此感到有些疑惑，因此我进行了一些调查。 简短的答案是，如果没有refspec，则git fetch url会FETCH_HEAD它们在HEAD拥有的所有内容，并将其放在您的FETCH_HEAD （请参见下文）。

git fetch三种模式

不计算“组”（这会使情况更加复杂）， git fetch命令允许的有用语法是以下三个中的一种，但一次仅一种：

1. git fetch remote [ refspecs ]
2. git fetch url [ refspecs ]
3. git fetch --multiple remote [ remotes ]

其中方括号表示可选的附加参数。

remote只是一个名称，例如origin ，您已将git存储在配置文件中。 当您第一次克隆存储库时，git为您创建名称origin 。 对于其他人，通常需要使用git remote add name url添加新的远程命名name 。 每个远程存储默认的一组获取引用规范以及URL ，当您运行git fetch ，如果您在命令行中省略了这些引用规范，则将使用这些引用规范。 （如果您提供至少一个refspec，则将忽略配置的默认值，而使用您提供的默认值。）

refspec确定要获取的内容。 一会儿，我将对此进行更多描述。

如果您直接指定URL而不是远程名称，则git在此处的行为仍然相同：它使用您提供的refspecs确定要获取的内容。 URL与命名的Remote的主要区别在于，URL 没有配置文件条目可提供默认的refspecs集 。 这意味着您应该至少提供一个refspec。 但是，如果不这样做，那么在这种情况下，默认的refspec只是HEAD 。 请参阅下面的内容。

（为完整--multiple ，最后一种形式带有--multiple ，它告诉git fetch 所有参数都是远程名称，而不是仅一个远程名称后跟一些refspec。在这种情况下，refspec都照常来自配置文件。换句话说--multiple只是告诉git的是，例如，你不是故意要取的Refspec github从origin时，你说git fetch --multiple origin github ，而是从远程读取origin也来自偏远然后github 。）

参考规格

我认为，Git的refspec是使用git的文献记载最少，最混乱的方面之一。 这令人惊讶，因为它们实际上非常简单而优雅，尽管您必须简单地学习并记住一些奇怪的地方。

refspec的通常形式是一对分支或标记名称，例如master:master或v1.2:v1.2 。 完整的表格说明了完整的参考名称，例如refs/heads/master或refs/tags/v1.2 ，还包括可选的前导加号+ （在此将忽略）。 甚至还有一个缩写形式，它仅由一个分支或标记名组成，例如master 。

有点令人困惑的是， fetch和push不是完全对称的。

首先，使用fetch ，将其分支名称放在左侧， 将您的名称放在右侧。 如果你想带分支master从远程到您的分支work ，你可以写为master:work 。 随着push ，不过，你把左边的分支名， 他们的名字右边：从您的推动work ，以自己的master ，你会写work:master 。 记住这一点的简单方法是，它总是from : to ，左侧是“源”，右侧是“目的地”。 提取的来源是“他们的东西”，而推送的来源是“您的东西”。

第二点，也是更重要的一点，如果使用fetch ，则如果只写一个名称，则“目标”部分默认为空：将获取的内容放在任何分支或标记上。 使用push ，“目标”部分默认使用一种相当复杂的方法，在此我将不介绍它，只是说它永远不会为空 。

通常，如果您带来一个分支，放置它的最佳位置是远程跟踪分支。 举例来说，如果你把在master从origin ，你应该把结果refs/remotes/origin/master （这是完全拼写形式origin/master ）。 同样，如果带上标签，放置标签的最佳位置也是标签。 如果您使用远程名称，则git将为您进行所有设置，而无需执行任何特殊操作，您只需git fetch origin并将其所有分支复制到带有特殊标签的远程跟踪分支中魔术完成了相应的标签。

但是，如果您不想使用远程跟踪分支，则可以使用git fetch仍然处理它带来的问题的更老的方式。 .git目录中有一个特殊文件git，名为FETCH_HEAD 。 每次抓取，甚至只是到URL的抓取，都会更新此文件（通常完全替换它，但使用-a或--append ，将旧内容保留在原位置，仅添加新内容）。 无论git fetch带来什么，它都会写入此文件。

这有两个含义：

1. 如果您通过参数提供refspec，但将其目标保留为空，则fetch将带入您命名的源，但仅将结果放入FETCH_HEAD 。
2. 如果您根本不提供任何refspecs，并且请记住，这仅适用于git fetch的仅URL形式，因为remote-name形式从配置文件^1中获取默认的refspecs，然后git fetch假装您给了HEAD ，将目的地留空。 这将带来HEAD ，并且与情况1一样，仅将结果放入FETCH_HEAD 。

特殊的HEAD引用是在遥控器上设置的任何HEAD 。 对于典型的“裸露”存储库， HEAD通常是指向分支master的符号引用，因此，默认的URL可能是FETCH_HEAD其master但仅将其放在FETCH_HEAD 。 但这取决于他们对HEAD参考的处理方式（当然，这是他们控制自己喜欢的方式）。

---

¹我实际上不确定配置文件中没有fetch = lines时会发生什么： git fetch将其视为“根本没有引用”，还是将其视为“我没有refspecs，所以提供了默认的HEAD refspec的目的地为空，例如网址”？