힘내 태그를 확인하면 "분리 HEAD 상태"가됩니다


166

내 자식 프로젝트의 배포 스크립트를 개발 중이며 방금 태그를 사용하기 시작했습니다. 다음과 같은 새로운 태그를 추가했습니다 v2.0.

git tag -a v2.0 -m "Launching version 2.0"

이 태그를 원격 저장소에 푸시했습니다

git push --tags

배포 스크립트를 실행하고 v2.0태그를 확인하려고 하면이 메시지가 나타납니다.

'분리 된 HEAD'상태입니다. 둘러보고 실험적으로 변경하고 커밋 할 수 있으며 다른 체크 아웃을 수행하여 분기에 영향을주지 않고이 상태에서 커밋을 버릴 수 있습니다. 생성 한 커밋을 유지하기 위해 새 브랜치를 만들려면 checkout 명령과 함께 -b를 다시 사용하여 지금 만들거나 나중에 할 수 있습니다. 예 : git checkout -b new_branch_name HEAD는 현재

그게 정상인가요? 내가 할 경우 저장소는 림보에 있습니다.

git branch

나는이 출력을 얻는다 :

* (no branch)
  master

이것이 명백하지만 죄송합니다. 알 수 없습니다.


"배포 스크립트 실행 및 v2.0 체크 아웃"이라고 말하면 코드가 "git checkout v2.0"처럼 보입니까? 릴리스 스크립트를 수정하려고하는데 프로덕션 시스템에서 "git checkout v2.0"을 실행하면 "오류 : pathspec 'v2.0'이 (가) git로 알려진 파일과 일치하지 않습니다." 비록 프로덕션에서 "git checkout v2.0"을 수행하기 전에 로컬 컴퓨터에서 "git push origin --tags"를 실행했지만 또한 "git checkout v2.0"을 호출하기 전에 프로덕션에서 "git pull --tags"및 "git fetch --tags"를 실행하려고 시도했지만 작동하지 않습니다 ... 여전히 오류. 어떤 아이디어?
John Erck

3
위의 주석을 삭제하려고했지만 계속 유지하면 다른 사람에게 도움이 될 수 있다고 생각했습니다. "git checkout v2.0"을 실행할 때 태그 이름에 TYPO가있어 오류가 발생했습니다. 그러나 오타 관련 오류는 "git fetch --tags"를 실행하기 전에 오타없이 "git checkout v2.0"을 실행하면 발생하는 것과 동일한 오류입니다. 따라서 궁극적으로 내 문제는 오타없이 "git checkout v2.0"을 실행하기 전에 "git fetch --tags"를 실행하여 해결되었습니다. 휴!
John Erck

예, fetch --tags 전에 fetch --tags (또는 원격에서 모두 가져 오는 git fetch)를 수행해야하므로 git이 태그를 체크 아웃 할 수 있습니다. 오늘 방금 당신의 의견을 보았습니다.
Khriz

답변:


429

먼저 몇 가지 용어가 약간 단순화되었습니다.

에서 gitA, tag(많은 다른 것들처럼)를 불렀다 무엇 treeish . 프로젝트의 역사에서 요점을 언급하는 방법입니다. 나무는 태그, 커밋, 날짜 지정자, 서수 지정자 또는 기타 여러 가지가 될 수 있습니다.

이제 branch 는 태그와 같지만 움직일 수 있습니다. 브랜치를 "켜고"커밋하면 브랜치는 현재 위치를 나타내는 새 커밋으로 이동합니다.

귀하 HEAD는 "현재"로 간주되는 지점에 대한 포인터입니다. 당신이 저장소를 복제 할 때 일반적으로 HEAD가리 킵니다 master커밋에 차례로 가리 킵니다있다. 그런 다음과 같은 작업을 수행 하면 다른 커밋 을 가리킬 수있는 분기 를 가리 키도록 git checkout experimental전환합니다 .HEADexperimental

이제 설명입니다.

을 수행하면 git checkout v2.0으로 지정되지 않은 커밋으로 전환됩니다 branch. 는 HEAD지금 "분리"와 지점을 가리키는되지 않습니다. 지금 커밋을하기로 결정했다면이 커밋을 추적하기 위해 업데이트 할 분기 포인터가 없습니다. 다른 커밋으로 다시 전환하면이 새로운 커밋을 잃게됩니다. 그것이 메시지가 말하는 것입니다.

일반적으로 할 수있는 일은을 말하는 것 git checkout -b v2.0-fixes v2.0입니다. 이렇게하면 커밋에서 나무가 가리키는 커밋 v2.0(이 경우 태그)에 새 분기 포인터가 만들어 지고이를 HEAD가리 키도록 이동합니다 . 이제 커밋을하면 v2.0-fixes분기를 사용하여 커밋을 추적 할 수 있으며 평상시처럼 작업 할 수 있습니다. v2.0코드를 보고 싶을 때 특히 수행 한 작업에 "잘못된"것은 없습니다 . 그러나 추적하려는 위치를 변경하려면 지점이 필요합니다.

git의 전체 DAG 모델을 이해하는 데 시간을 투자해야합니다. 놀랍도록 간단하고 모든 명령을 명확하게 만듭니다.


감사합니다. 코드를 변경할 필요가 없으므로 괜찮습니다. 지점을 만들 필요가 없습니다. 고마워요!
Khriz

1
나는이 대답을 처음 보았을 때 길을 잃었지만 Git 분기 설명서를 읽은 후 http://git-scm.com/book/en/Git-Branching-What-a-Branch- 그것은 훨씬 명확했습니다. .
마크 스타일스

3
멋진 답변이지만 "다른 커밋으로 다시 전환하면이 새로운 커밋을 잃게됩니다."— 커밋을 계속 찾을 수 있습니다 git reflog. 가비지 수집이 발생하지 않으면 커밋을 잃는 것은 "불가능"해 보입니다.
Dmitry Minkovsky

가비지 수집 작업으로 인해 참조되지 않은 커밋이 손실 될 수 있습니다.
누팔 이브라힘

1
그들이 페이지의 레이아웃을 변경했기 때문에 URL이 잘못되었습니다.
jcubic

12

예, 정상입니다. 이는 헤드가없는 단일 커밋을 체크 아웃하기 때문입니다. 특히 (더 이상) 지점의 헤드가 아닙니다.

그러나 일반적으로 해당 상태에는 문제가 없습니다. 안전하다고 느끼면 태그에서 새 브랜치를 만들 수 있습니다. :)


1
좋아, 나는 그렇게 유지합니다 ... 어쨌든 안전은 과대 평가;)
Khriz

당신이 Noufals의 답변에 언급 한대로 (더 나은 대답은;;라고 말해야합니다.) : 아무것도 바꾸지 않는 한 걱정할 것이 없습니다. 그러나을 변경하고 무언가를 변경할 수 있다고 가정 하면 git이 저렴하여 분기를 삭제하고 나중에 다시 생성 할 수 있기 때문에 분기를 만들 수 있습니다.
KingCrunch
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.