Git의 태그는 브랜치와 비슷한데 브랜치처럼 가리키는 지점을 최신 커밋으로 이동시키지 않는다. 단순히 특정 커밋에 대한 포인터일 뿐이다.
보통 Release할 때 사용하며(v1.0 등등) Git을 우아하게 다루기 위해 태그를 잘 알아두는 것이 좋다!
태그 종류, 조회, 생성, 삭제에 관해 알아보자.
태그 종류
태그는 Lightweight 태그와 Annotated 태그 두 종류가 있다.
Lightweight 태그는 따로 정보를 저장하지 않고 단순한 태그가 필요할 경우 사용한다.
Annotated 태그는 Git 데이터베이스에 태그를 만든 사람의 이름, 이메일과 태그를 만든 날짜, 그리고 태그 메시지도 저장한다. GPG(GNU Privacy Guard)로 서명할 수도 있다. 이 모든 정보를 저장해둬야 할 때만 사용하길 추천한다.
태그 조회하기
git tag 명령으로 이미 만들어진 태그가 있는지 확인할 수 있다.
Annotated 태그 생성
git tag -a 명령을 통해 Annotated 태그를 생성할 수 있다. 또한, 메시지를 추가하기 위해 -m 옵션을 추가하면 된다(-m 옵션을 추가해놓고 메시지를 추가하지 않았을 경우 Git은 편집기를 실행시킨다).
git show <tag-name> 명령으로 태그 정보와 커밋 정보를 모두 확인할 수 있다.
커밋 정보를 보여주기 전에 먼저 태그를 만든 사람(Tagger)이 누구인지, 언제 태그를 만들었는지(Date), 그리고 태그 메시지가 무엇인지(여기선 “my version 1.0.0”) 보여준다.
Lightweight 태그 생성
Lightweight 태그는 기본적으로 파일에 커밋 체크섬을 저장하는 것뿐이다. 다른 정보는 저장하지 않는다. Lightweight 태그를 만들 때는 -a, -s, -m 옵션을 사용하지 않는다.
이 태그에 git show 명령을 실행하면 별도의 태그 정보를 확인할 수 없다. 단순히 커밋 정보만을 보여줄 뿐이다.
나중에 태그하기
예전 커밋에도 태그할 수 있다. 커밋 히스토리는 아래와 같다고 가정한다.
“removed unnecessary test code” 커밋을 v0.0.3로 태그하지 못했다고 해도 나중에 태그를 붙일 수 있다. 특정 커밋에 태그하기 위해서 명령의 끝에 커밋 체크섬을 명시한다. 참고로 긴 체크섬을 전부 명시 할 필요는 없다.
※ 앞에서 설명했듯이 태그는 특정 커밋(여기서는 085bb3b…)을 포인팅할 뿐, HEAD는 해당 커밋을 가리키지는 않는다.
태그 삭제하기
git tag -d <tag-name> 명령을 통해 Lightweight, Annotated 태그 모두 삭제할 수 있다.
태그 공유하기
git push 명령은 자동으로 리모트 서버에 태그를 전송하지 않는다. 태그를 만들었으면 서버에 별도로 Push해야 한다. 브랜치를 공유하는 것과 같은 방법으로 할 수 있다. git push origin <tag-name> 명령을 통해 리모트 서버에 Push 한다.
만약 한번에 태그를 여러 개 Push하고 싶으면 --tags 옵션을 추가하여 git push 명령을 실행한다.
git push origin --tags
이제 누군가 저장소에서 Clone하거나 Pull하면 모든 태그 정보도 함께 전송된다.
태그 Checkout 하기
태그는 브랜치와 달리 가리키는 커밋을 바꿀 수 없기 때문에 Checkout해서 사용할 수 없다. 태그가 가리키는 특정 커밋을 기반으로 하는 브랜치를 만들어 작업하려면 아래와 같이 새로 브랜치를 생성해야 한다.
HEAD가 br_version2로 이동됨에 따라 해당 v0.0.4 태그 이후에 존재하던 3개의 커밋이 보이지 않게 됐다(영구적으로 사라진 것은 아니다). 물론 이렇게 브랜치를 만든 후에 br_version2 브랜치에서 커밋하면 브랜치 내용은 업데이트 된다. 하지만 v0.0.4 태그는 가리키는 커밋이 변하지 않았으므로 브랜치 br_version2와 태그 v0.0.4가 가리키는 커밋이 서로 다르다는 것을 알 수 있다.
보다시피 a11bef0 커밋에서 내용 수정 후 커밋 하니깐 3337aae 커밋이 새로 생성되었고, HEAD 또한 변경되었다. 반면 태그는 그대로 a11bef0 커밋을 포인팅하고 있다. 이러한 태그의 특성으로 인해 발현된 상태를 Git에서 Detached HEAD state라고 정의한다. 반대로 HEAD가 브랜치를 통해 커밋을 가리키는 상태를 Attached HEAD state라고 정의한다.