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

是否有任何命令，使用单个命令获取远程中的所有更改。 fetch url和fetch origin之间也有区别。

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/

（正如我在this answer中提到的那样）

当您直接使用网址时，本地配置中没有respec来指示Git要获取的内容。

Answer 2

你养成使用origin或github这样的远程名称的习惯可能要好得多，但我自己也在想这个，所以我调查了一下。简短的回答是，如果没有refspec，git fetch url会带来HEAD中的所有内容，并将其放在FETCH_HEAD中（见下文）。

`git fetch`

的三种模式

不计算＆＃34;小组＆＃34; （这更加复杂），git fetch命令允许的有用语法是一个 - 但一次只有一个 - 以下三个：

git fetch remote [refspecs]
git fetch url [refspecs]
git fetch --multiple remote [remotes]

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

remote 只是一个名称，如origin，您已在配置文件中存储了git。首次克隆存储库时，git会为您创建名称origin;对于其他人，您通常希望使用git remote add name url添加名为 name 的新远程。 每个远程存储一组默认的fetch refspecs以及URL ，当你运行git fetch时，如果你从命令行中省略它们，这些就是使用的refspec。（如果您提供至少一个refspec，则会忽略配置的默认值，而是使用您提供的默认值。）

refspecs确定要获取的内容。我稍后会对此进行更多描述。

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

（为了完整性，最后一个表单--multiple，只是告诉git fetch 所有参数是远程名称，而不仅仅是一个远程名称，后跟一些refspecs在这种情况下，refspecs都像往常一样来自配置文件。换句话说，--multiple只是告诉git，例如，你并不是要在github时从origin获取refspec git fetch --multiple origin github说origin，而是从远程github获取，然后从远程master:master获取。）

Refspecs

我认为Git的refspecs是使用git最少记录和最混乱的方面之一。这是令人惊讶的，因为它们实际上非常简单和优雅，尽管有一些奇怪的东西你必须简单地学习和记忆。

refspec的常用形式只是一对分支或标记名称，例如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，使用＆＃34;来源＆＃34;在左边和＆＃34;目的地＆＃34;在右边。获取的来源是＆＃34;他们的东西＆＃34;但推动的来源是＆＃34;你的东西＆＃34;。

第二个也是更重要的是，push，如果只编写一个名称，＆＃34;目的地＆＃34; part默认为empty：将获取的内容放在 no 分支或标记上。使用master，＆＃34;目的地＆＃34;部分默认为一个相当复杂的方法，我不会在这里描述，除非说它永远不会为空。

通常情况下，如果你带来一个分支，最好的位置是远程跟踪分支。例如，如果您从origin带来refs/remotes/origin/master，则应将结果放在origin/master（这是git fetch origin的完全拼写形式）中。同样，如果你带一个标签，放置它的最佳位置也是一个标签。如果您使用远程名称，git会为您设置所有这些，并且您不必做任何特殊事情，只需git fetch并将所有分支复制到您自己的远程跟踪分支机构，对相应的标签进行特殊标记魔术。

但是，如果您不想使用远程跟踪分支，则可以使用.git仍处理其带来的内容的更古老的方式。有一个特殊的文件git保存在名为FETCH_HEAD的{{1}}目录中。每次获取，即使只是一个URL，都会更新此文件（通常完全替换它，但使用-a或--append，保留旧内容并添加新内容）。无论git fetch带来什么，它都会写入此文件。

这有两个含义：

如果您通过参数提供refspecs，但将其目的地保留为空，fetch会将您命名的来源带回来，但只将结果放入FETCH_HEAD。
如果您根本不提供任何refspec-并且请记住，这只能使用仅限git fetch的网址形式，因为远程名称表单会获得配置文件中的默认refspec ¹ - 然后git fetch假装你给它HEAD，这使目的地为空。这会带来HEAD，与案例1一样，仅将结果放入FETCH_HEAD。

特殊HEAD引用是远程设置的HEAD。有一个典型的＆＃34;裸＆＃34;存储库HEAD通常是指向分支master的符号引用，因此您使用网址的默认设置可能是将master带入，但只将其放在您的{{1}中}}。但这取决于他们对{{1}}引用所做的事情（当然，无论他们喜欢什么，都可以控制他们）。

¹我真的不确定当配置文件没有FETCH_HEAD行时会发生什么：HEAD将此视为＆＃34;带来否refs to all＆＃34;，或者是否将其视为＆＃34;我没有refspecs所以提供默认的fetch = refspec与空目的地，la URL＆＃34;？

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

2 个答案:

`git fetch`

Refspecs