“git fetch --tags”에“git fetch”가 포함됩니까?


270

훌륭하고 간단한 질문- "git fetch"의 기능은 git fetch --tags?

즉, 내가 달리면 바로 후에 git fetch --tags바로 달리는 이유가 git fetch있습니까?

무엇에 대한 git pull그리고 git pull --tags? 같은 상황?


11
힘내 .. 9 / 2.0 (Q1 2014) 시작, 대답은 될 것입니다 예 . 아래 답변을
— VonC

3
편집으로 "내 텍스트를 수정 한"편집자에게-하이픈이나 약어 뒤에 반드시 대문자를 사용할 필요는 없으므로 편집이 문법적으로 잘못 되었기 때문에 거부했습니다.
— davidA

답변:


176

참고 :로 시작하는 자식 1.9 / 2.0 (Q1 2014) , git fetch --tags태그를 가져옵니다 에 추가 옵션없이 같은 명령 라인으로 가져온 무엇인지.

참조 c5a84e9 커밋 에 의해 마이클 Haggerty (mhagger) :

이전에는 페치의 " --tags"옵션이 참조 스펙을 지정하는 것과 동등한 것으로 간주되었습니다

refs/tags/*:refs/tags/*

명령 행에서; 특히 remote.<name>.refspec구성이 무시되었습니다.

그 반면 그러나, 다른 참조를 가져 오는없이 태그를 가져올 수 유용하지 않다 이다 태그를 가져올 수있는 것이 매우 유용 외에 다른 참조.
따라서이 옵션의 의미를 변경하여 후자를 수행하십시오.

사용자가 태그 만 가져 오려면 여전히 명시 적 참조 사양을 지정할 수 있습니다.

git fetch <remote> 'refs/tags/*:refs/tags/*'

1.8.0.3 이전의 문서는 " fetch --tags"동작 의 이러한 측면에 대해 모호했습니다 .
커밋 f0cb2f1 (2012-12-14) fetch --tags은 문서가 이전 동작과 일치하도록했습니다.
이 커밋은 새로운 동작과 일치하도록 설명서를 변경합니다 (참조 Documentation/fetch-options.txt).

가져 오는 태그 외에 모든 태그를 원격 에서 가져 오도록 요청하십시오 .


Git 2.5 (2015 년 2 분기) 이후 git pull --tags더 강력합니다.

참조 19d122b 커밋 에 의해 폴 탄 ( pyokagan) 5 월 13 일 2015 년
(에 의해 합병 Junio C 하마노 - gitster- 에 cc77b99을 투입 , 2015 (22) 5 월)

pull: --tags병합 후보가없는 경우 오류 제거

이후 441ed41 ( " git pull --tags". 더 나은 메시지 초과 오류, 2007-12-28는, 힘내 1.5.4+), git pull --tags경우 다른 오류 메시지를 인쇄 할 git-fetch모든 병합 후보를 반환하지 않았습니다 :

It doesn't make sense to pull all tags; you probably meant:
       git fetch --tags

그 당시에 git-fetch --tags는 구성된 참조 사양을 재정의하므로 병합 후보가 없기 때문입니다. 따라서 혼란을 방지하기 위해 오류 메시지가 도입되었습니다.

그러나 이후 c5a84e9 ( fetch --tags: 태그 가져올 뿐만 아니라 , 다른 재료, 2013년 10월 30일, 힘내 1.9.0+) git fetch --tags모든 구성 refspecs에 추가로 태그를 가져올 것입니다.
따라서, 병합 후보 상황이 발생하지 않으면, --tags설정 되었기 때문이 아닙니다 . 따라서이 특수 오류 메시지는 이제 관련이 없습니다.

혼동을 피하려면이 오류 메시지를 제거하십시오.


Git 2.11+ (2016 년 4 분기)를 사용 git fetch하면 더 빠릅니다.

Jeff King ( )의 commit 5827a03 (2016 년 10 월 13 일)을 참조하십시오 . ( Junio ​​C Hamano 에 의해 합병 -- 커밋 9fcd144 , 2016 년 10 월 26 일)peff
gitster

fetch: has_sha1_file태그 다음에 "빠른"사용

우리가 따르고있는 브랜치와 관련이없는 많은 태그가있는 리모콘에서 가져올 때 우리는 태그에 의해 지정된 객체 (페치하지 않을 것입니다!)가 저장소에 있는지 확인할 때 너무 많은 사이클을 낭비했습니다. 너무 조심스럽게

이 패치는 fetch가 HAS_SHA1_QUICK를 사용하여 동시 재 포장으로 인해 정확성이 떨어지는 경우 속도의 정확도를 희생하도록 지시합니다.

포함 된 perf 스크립트의 결과는 위에서 설명한 것과 유사한 상황을 설정합니다.

Test            HEAD^               HEAD
----------------------------------------------------------
5550.4: fetch   11.21(10.42+0.78)   0.08(0.04+0.02) -99.3%

이는 다음과 같은 상황에만 적용됩니다.

  1. 클라이언트 측에 많은 팩을 가지고 있기 때문에 reprepare_packed_git()비용이 많이 듭니다 (가장 비싼 부분은 정렬되지 않은 목록에서 현재 2 차인 중복 항목을 찾는 것입니다).
  2. 서버 측에서 자동 추적을 수행 할 수있는 많은 수의 태그 참조가 필요합니다 (즉, 클라이언트에없는 태그 참조). 각각은 팩 디렉토리를 다시 읽습니다.
  3. 정상적인 상황에서 클라이언트는 해당 태그를 자동으로 따르고 한 번의 큰 페치 후에는 (2) 더 이상 사실이 아닙니다.
    그러나 해당 태그가 히스토리를 가리키면 클라이언트가 가져 오는 것과 연결이 끊어지면 자동으로 팔로우되지 않으며 해당 후보는 모든 페치에 영향을 미칩니다.

Git 2.21 (2019 년 2 월)은 구성 remote.origin.fetch이 기본 구성 이 아닌 경우 회귀를 도입 한 것으로 보입니다 ( '+refs/heads/*:refs/remotes/origin/*')

fatal: multiple updates for ref 'refs/tags/v1.0.0' not allowed

Git 2.24 (2019 년 4 분기)에는 또 다른 최적화가 추가되었습니다.

Masaya Suzuki ( )의 commit b7e2d8b (2019 년 9 월 15 일)를 참조하십시오 . (가 합병 - Junio C 하마노 - 에 1d8b0df 커밋 2019 07 10 월)draftcode
gitster

fetch: oidset빠른 조회를 위해 원하는 OID를 유지하는 데 사용

동안 git fetch클라이언트 검사, 광고 된 태그 'OID를 이미 가져 오기 요청의에 OID 세트를 원하는 경우.
이 검사는 선형 스캔으로 수행됩니다.
참조 횟수가 많은 리포지토리의 경우이 검색을 반복하는 데 15 분 이상이 걸립니다.

이 속도를 높이려면 oid_set다른 심판의 OID를 만드십시오 .


git-list의이 스레드는 git fetch <remote> <branch>태그를 자동 추적 하는 동작을 수정하는 가능성에 대해 설명합니다 (원래 의도에 따라 원격 추적을 이미 업데이트하므로) : public-inbox.org/git/…
— ankostis

@ankostis 흥미 롭다 : Junio가 public-inbox.org/git/… 에서 언급 했듯이 , "이전 스레드로 논의되는 문제를 해결하기 위해서는 이전의 동작으로 돌아가는 것이 하나의 옵션 일 수 있습니다." (그러나 그들은하지 않습니다 : public-inbox.org/git/… )
— VonC

Git이 일반적인 작업을 수행하기 위해 해킹과 유사한 지점에 구문이 많은 명령을 요구하여 최종 사용자에게 더 복잡한 복잡성을 노출시킬 수 있었습니까? 나는 아직 충분한 내부 지식이 필요한 지식이라고 생각하지 않습니다.
— John Fantastico

1
@ JohnFantastico 그 관점을 이해할 수 있습니다. 이전에 news.ycombinator.com/item?id=16587496을 보았습니다 . 또는 hackernoon.com/… ( "Git 명령은 데이터 저장소에 대해 유출 된 추상화 일뿐입니다.")
— VonC

1
@Vadorequest 감사합니다. 답변을 업데이트했으며 메일 링리스트를 계속 살펴볼 것입니다 : public-inbox.org/git/?q=fetch
— VonC

131

참고 :이 답변은 git v1.8 이상에서만 유효합니다.

이것의 대부분은 다른 답변과 의견에서 언급되었지만 간결한 설명이 있습니다.

  • git fetch모든 브랜치 헤드 (또는 remote.fetch config 옵션으로 지정된 모든), 페치에 필요한 모든 커밋 및이 브랜치에서 도달 할 수있는 모든 태그를 가져옵니다. 대부분의 경우 이러한 방식으로 모든 태그에 도달 할 수 있습니다.
  • git fetch --tags모든 태그, 필요한 모든 커밋을 가져옵니다. 그것은 것입니다 하지 그들이 가져온했다 태그에서 연결할 경우에도 브랜치 헤드를 업데이트합니다.

요약 : 페치 만 사용하여 완전히 최신 상태를 유지하려면 둘 다 수행해야합니다.

명령 줄에 입력하는 것을 의미하지 않는 한 "두 번 느리게"되지 않습니다.이 경우 별칭이 문제를 해결합니다. 서로 다른 정보를 요구하기 때문에 두 요청을하는 데에는 실질적으로 오버 헤드가 없습니다.


2
귀하의 의견에 감사드립니다. 대기 시간이 긴 네트워크를 통해 Cygwin에서 git을 실행 중입니다. 약 5 초 동안 아무것도 가져올 것이 없으면 두 배 느립니다.
— davidA

오 와우. git-remote가 더 잘 작동합니까? 소스를 간략하게 살펴보면 한 번만 호출 할 수 있다고 생각하지만 지점이 아닌 태그를 가져올 지 확실하지 않습니다. 솔직히 지점에없는 태그를 본 적이 있는지 모르겠습니다. 내가 가져온 것들로 인해 유지 보수 릴리스, 기능 릴리스 및 이전 릴리스의 유지 보수 중단을 놓칠 정도로 오래 기다렸을 때 발생하는 유일한 방법입니다.
— Cascabel

문제는 'git fetch'가 추적 된 분기의 태그 만 가져 오는 것 입니다. 우리는 사용자가 워킹 브랜치를 선택할 수 있도록하는 스크립트를 가지고 있으므로, 기본적으로 개인이 현재 추적하지 않는 많은 브랜치가 있습니다.
— davidA

나는 아직 git-remote를 시도하지는 않았지만, 그것은 계속 성장하는 할 일 목록에있다 :)
— davidA

7
주 git remote update사실을 대신 할 수는 없습니다 git fetch와 git fetch --tags. git remote update변경된 기존 태그는 업데이트하지 않지만 새 태그를 가져옵니다. git fetch --tags기존 태그 만 업데이트합니다.
— larsks

48

나는 이것에 스스로 대답 할 것이다.

차이가 있다고 판단했습니다. "git fetch --tags"는 모든 태그를 가져올 수 있지만 새로운 커밋은 가져 오지 않습니다!

완전히 "최신"상태가되도록하기 위해, 즉 병합없이 "git pull"을 복제해야합니다.

$ git fetch --tags
$ git fetch

두 배나 느리기 때문에 부끄러운 일입니다. "git fetch"만이 정상적으로 수행하는 옵션이 있고 모든 태그를 가져옵니다.


흥미롭게도, 나는 그것을 경험하지 못했습니다 (아마도 레포가 테스트 당시 최신 상태 였기 때문일 것입니다). +1
— VonC

1
git remote update myRemoteRepo원격 컨텐츠 와 태그 를 가져 오는 ' '는 어떻습니까?
— VonC

1
나는 git fetch항상하고 새로운 커밋 과 새로운 태그를 지속적으로 끌어냅니다 . 어떤 버전의 Git을 사용하고 있습니까?
— Tim Visher

4
FTR, 'git remote update myRemoteRepo'가 제대로 작동하지 않습니다. 'git fetch && git fetch --tags'가 수행하는 작업을 수행하지 않는 것 같습니다. 특히 후속 병합이 효과가 없습니다.
— davidA

1
@TimVisher git fetch는 분기의 커밋 로그에없는 태그를 가져 오지 않습니다. jQuery UI는 예를 들어 릴리스 태그에서이를 수행합니다. 우리는 git checkout -b temp-branch릴리스를 수행하고 릴리스에 필요한 파일을 추가하고 버전을 업데이트 한 git commit -m "1.10.x" ; git tag 1.10.x; git push --tags다음 로컬 임시 분기를 삭제합니다. 해당 태그에 도달하는 원격 브랜치 git fetch는 없으며 다운로드하지 않습니다.
— gnarf

31

여기서 일반적인 문제 git fetch는 fetch +refs/heads/*:refs/remotes/$remote/*입니다. 이러한 커밋에 태그가 있으면 해당 태그도 가져옵니다. 그러나 원격의 어떤 분기에서도 도달 할 수없는 태그가 있으면 가져 오지 않습니다.

이 --tags옵션은 참조 스펙을로 전환합니다 +refs/tags/*:refs/tags/*. 당신은 할 수 요청 git fetch을 모두 잡아. 나는 단지 어떻게 확신 git fetch && git fetch -t다음 명령을 사용하십시오 :

git fetch origin "+refs/heads/*:refs/remotes/origin/*" "+refs/tags/*:refs/tags/*"

그리고 이것을이 저장소의 기본값으로 설정하려면 기본 가져 오기에 두 번째 참조 스펙을 추가 할 수 있습니다.

git config --local --add remote.origin.fetch "+refs/tags/*:refs/tags/*"

이 리모컨 fetch =에 두 번째 줄 이 추가됩니다 .git/config.


나는 프로젝트를 위해 이것을 처리하는 방법을 찾는 데 시간을 보냈습니다. 이것이 내가 생각해 낸 것입니다.

git fetch -fup origin "+refs/*:refs/*"

제 경우에는 이러한 기능을 원했습니다

  • 리모콘에서 모든 헤드와 태그를 가져 와서 refspec을 사용하십시오. refs/*:refs/*
  • 참조 +스펙 이전에 로컬 브랜치 및 태그를 빨리 감기로 덮어 쓰기
  • 필요한 경우 현재 체크 아웃 한 분기 덮어 쓰기 -u
  • 원격에없는 브랜치 및 태그 삭제 -p
  • 그리고 강제로 -f

이것이 답이되어야합니다.
— redolent

"이 --tags옵션은 참조 스펙을 +refs/tags/*:refs/tags/*"으로 전환합니다 . , man git-fetch선행 +( refs/tags/*:refs/tags/*) 없이 refspec을 지정하는 것으로 보입니다 .
— Dmitry Minkovsky

remote.origin.fetch기본값은 +refs/heads/*:refs/remotes/origin/*, 즉 +버전이 아닌가? (즉, 원산지 / 지점이 현재 지역에 상관없이 원산지 / 지점을 덮어 씁니다.)
— Robert Siemer

... 그리고 글을 쓰는 시점에서 최근 git --tags에는 이미 다른 모든 것 외에도 태그 를 가져 왔습니다 . @VonC의 답변을 참조하십시오.
— Robert Siemer

10

대부분의 경우 git fetch원하는 작업을 수행해야합니다. 즉, '원격 저장소에서 새로운 것을 가져 와서 로컬 브랜치에 병합하지 않고 로컬 사본에 넣습니다'입니다. git fetch --tags새로운 태그 이외의 것을 얻지 못한다는 점을 제외하고는 정확히 그렇게합니다.

그런 의미 git fetch --tags에서 결코의 슈퍼 세트가 아닙니다 git fetch. 실제로는 정반대입니다.

git pull물론,에 대한 래퍼 일뿐입니다 git fetch <thisrefspec>; git merge. 처음에 무엇을하고 있는지 이해하는 데 도움이되기 때문에 단순히 점프하기 전에 수동 git fetching과 git mergeing에 익숙해지는 것이 좋습니다 .git pullgit pull

즉, 관계는와 정확히 동일합니다 git fetch. git pull의 슈퍼 세트입니다 git pull --tags.


1
"git pull은 git pull --tags의 수퍼 세트입니다."-... 'git fetch'는 'git fetch --tags'의 수퍼 세트 가 아니기 때문에 관계가 정확히 같지 않습니까?
— davidA

9
그냥 잘, 그 날 것으로 보인다 ...이 질문을 발견 git pull않습니다 하지 얻을 모든 태그를하지만 현재 브랜치 헤드에서 만 도달. 그러나 git pull --tags모든 태그를 가져오고 분명히 같습니다 git fetch --tags.
— Archimedix

2
git fetch upstream --tags

제대로 작동하면 새 태그 만 가져오고 다른 코드베이스는 얻지 않습니다.


1
upstream일반적으로이라고 origin합니다. upstreamGitHub에서 사용하는 이름 이라고 생각 합니다. 어쨌든 사용할 이름은로 표시됩니다 git remote.
— Fabio는 Reinstate Monica가
당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.