TA貢獻(xiàn)1828條經(jīng)驗(yàn) 獲得超13個(gè)贊
注意：從git 1.9 / 2.0（Q1 2014）開始，除了在同一命令行中不帶選項(xiàng)的情況下，還將git fetch --tags獲取標(biāo)簽。
見提交c5a84e9由邁克爾·哈格蒂（mhagger） ：
以前，fetch的“ --tags”選項(xiàng)被認(rèn)為等同于指定refspec
refs/tags/*:refs/tags/*
在命令行上；特別是，它導(dǎo)致該remote.<name>.refspec配置被忽略。
但它并非沒有取也是其他參考獲取標(biāo)簽是非常有用的，而它是能夠抓取代碼非常有用，除了其他的引用。
因此，請(qǐng)更改此選項(xiàng)的語(yǔ)義以執(zhí)行后者。
如果用戶想要獲取唯一的標(biāo)簽，那么它仍然可以指定一個(gè)明確的Refspec：
git fetch <remote> 'refs/tags/*:refs/tags/*'
請(qǐng)注意，1.8.0.3之前的文檔在fetch --tags行為方面沒有明確規(guī)定。
提交f0cb2f1（2012-12-14）fetch --tags使文檔與舊行為匹配。
此提交更改了文檔以匹配新行為（請(qǐng)參閱參考資料Documentation/fetch-options.txt）。
要求除了獲取其他內(nèi)容外，還從遠(yuǎn)程獲取所有標(biāo)簽。
由于Git 2.5（2015年第二季度）git pull --tags更強(qiáng)大：
參見Paul Tan（）提交的commit 19d122b，2015年5月13日。（由Junio C Hamano合并--在cc77b99提交中，2015年5月22日）pyokagan
gitster
pull：--tags在沒有合并候選者的情況下刪除錯(cuò)誤
自441ed41（“ git pull --tags”：出現(xiàn)錯(cuò)誤時(shí)，出現(xiàn)了一條更好的消息。，2007-12-28，Git 1.5.4+），git pull --tags如果git-fetch未返回任何合并候選者，則會(huì)打印出另一條錯(cuò)誤消息 ：
It doesn't make sense to pull all tags; you probably meant:
git fetch --tags
這是因?yàn)槟菚r(shí)git-fetch --tags將覆蓋所有已配置的refspec，因此將沒有合并候選者。因此引入了錯(cuò)誤消息以防止混淆。
但是，由于c5a84e9（fetch --tags：除了 其他內(nèi)容外，還可以獲取標(biāo)簽，2013-10-30，Git 1.9.0+），git fetch --tags可以獲取任何已配置的refspec 之外的標(biāo)簽。
因此，如果沒有任何合并候選者的情況發(fā)生，那不是因?yàn)?-tags被設(shè)置。因此，此特殊錯(cuò)誤消息現(xiàn)在不相關(guān)。
為避免混淆，請(qǐng)刪除此錯(cuò)誤消息。
使用Git 2.11+（2016年第四季度）git fetch更快。
參見Jeff King（）提交5827a03（2016年10月13日）。（由Junio C Hamano合并--在commit 9fcd144中，2016年10月26日）peff
gitster
fetch：使用“快速” has_sha1_file進(jìn)行標(biāo)記跟蹤
當(dāng)從具有很多與分支無(wú)關(guān)的標(biāo)簽的遠(yuǎn)程進(jìn)行提取時(shí)，我們通常會(huì)在檢查存儲(chǔ)庫(kù)中是否存在由標(biāo)簽指向的對(duì)象（我們不會(huì)提?。。r(shí)浪費(fèi)了太多的時(shí)間。太小心了
此修補(bǔ)程序告訴fetch使用HAS_SHA1_QUICK犧牲準(zhǔn)確性以提高速度，以防我們可能因同時(shí)重新打包而感到厭倦。
以下是所包含的perf腳本的結(jié)果，該腳本設(shè)置了與上述情況類似的情況：
Test HEAD^ HEAD
----------------------------------------------------------
5550.4: fetch 11.21(10.42+0.78) 0.08(0.04+0.02) -99.3%
這僅適用于以下情況：
您在客戶端有很多包裝，reprepare_packed_git()價(jià)格昂貴（最昂貴的部分是在未排序的列表中查找重復(fù)項(xiàng)，該列表目前是二次的）。
您需要在服務(wù)器端有大量的標(biāo)記引用，這些標(biāo)記引用可以自動(dòng)跟蹤（即客戶端沒有）。每一個(gè)都會(huì)觸發(fā)對(duì)pack目錄的重新讀取。
在正常情況下，客戶端會(huì)自動(dòng)關(guān)注這些標(biāo)簽，并且在進(jìn)行一次大抓取后，（2）將不再為真。
但是，如果這些標(biāo)記指向的歷史與客戶端獲取的內(nèi)容斷開連接，那么它將永遠(yuǎn)不會(huì)自動(dòng)關(guān)注，并且這些候選對(duì)象將在每次獲取時(shí)對(duì)其進(jìn)行影響。
Git的2.21（2019年2月）似乎已經(jīng)引入了回歸時(shí)的配置remote.origin.fetch是不是默認(rèn)的（'+refs/heads/*:refs/remotes/origin/*'）
fatal: multiple updates for ref 'refs/tags/v1.0.0' not allowed
Git 2.24（2019年第四季度）增加了另一個(gè)優(yōu)化。
請(qǐng)參閱Masaya Suzuki（）的commit b7e2d8b（2019年9月15日）。（由Junio C Hamano合并--在commit 1d8b0df中，2019年10月7日）draftcode
gitster
fetch：用于oidset保留想要的OID以便更快地查找
在期間git fetch，客戶端檢查廣告標(biāo)記的OID是否已經(jīng)在獲取請(qǐng)求的OID集中。
該檢查是在線性掃描中完成的。
對(duì)于具有大量引用的存儲(chǔ)庫(kù)，重復(fù)此掃描需要15分鐘以上。
為了加快速度，請(qǐng)oid_set為其他裁判的OID 創(chuàng)建一個(gè)。
TA貢獻(xiàn)1848條經(jīng)驗(yàn) 獲得超6個(gè)贊
注意：此答案僅對(duì)git v1.8及更早版本有效。
在其他答案和評(píng)論中已經(jīng)說了大部分，但這是一個(gè)簡(jiǎn)潔的解釋：
git fetch獲取所有分支頭（或所有由remote.fetch config選項(xiàng)指定的分支頭），它們所需的所有提交以及從這些分支可訪問的所有標(biāo)記。在大多數(shù)情況下，所有標(biāo)簽都可以通過這種方式訪問。
git fetch --tags獲取所有標(biāo)簽，并完成所有必需的提交。即使從提取的標(biāo)簽可以到達(dá)分支頭，它也不會(huì)更新。
簡(jiǎn)介：如果您真的想完全保持最新，僅使用訪存，則必須同時(shí)進(jìn)行。
除非您是在命令行中輸入，否則它也不會(huì)“慢兩倍”，在這種情況下，別名可以解決您的問題。發(fā)出兩個(gè)請(qǐng)求基本上沒有開銷，因?yàn)樗鼈円蟮氖遣煌男畔ⅰ?/p>
TA貢獻(xiàn)1818條經(jīng)驗(yàn) 獲得超7個(gè)贊
我將自己回答。
我確定有區(qū)別?！?git fetch --tags”可能會(huì)引入所有標(biāo)簽，但不會(huì)帶來任何新的提交！
事實(shí)證明，這樣做必須完全“最新”，即在沒有合并的情況下復(fù)制了“ git pull”：
$ git fetch --tags
$ git fetch
真可惜，因?yàn)樗俣嚷藘杀?。如果只有?git fetch”可以選擇執(zhí)行其通常的操作并引入所有標(biāo)簽
舉報(bào)