핵심 정리

# annotated tag 생성
git tag -a v1.0.0 -m "Release 1.0.0"

# 원격에 tag 전송 (커밋 push와 별개다)
git push origin v1.0.0

# 모든 tag를 원격에 전송
git push origin --tags

문법

어떤 릴리스 기준점을 먼저 떠올리면 되나

브랜치와 tag의 근본적인 차이 — 움직이는 포인터 vs 고정된 기준점

Git에서 브랜치는 커밋을 가리키는 ref인데, 새 커밋이 생길 때마다 자동으로 앞으로 이동한다. 반면 tag는 특정 커밋 해시를 영구적으로 가리키는 고정 ref다. 한 번 생성한 tag는 일반적으로 이동하거나 변경하지 않는다. 이 고정성 덕분에 "v1.2.3 배포 시점의 코드가 정확히 무엇이었나"를 나중에 언제든 재현할 수 있다. 운영 사고가 발생했을 때 배포 당시 코드로 되돌리거나, 회귀 분석에서 특정 버전 사이의 diff를 확인하는 상황에서 tag가 없으면 커밋 해시를 수동으로 추적해야 하는 번거로움이 생긴다.

lightweight tag와 annotated tag의 차이 — release에는 annotated가 적합하다

lightweight tag는 커밋 해시를 가리키는 단순 ref 파일이다. git tag v1.0.0처럼 만들면 되지만 작성자, 날짜, 메시지 같은 메타데이터가 없다. annotated tag는 별도의 tag 객체를 Git 객체 데이터베이스에 생성하며 tagger 정보, 날짜, 서명(GPG) 등을 포함할 수 있다. release 용도라면 "누가 언제 어떤 의도로 이 기준점을 만들었는가"를 남길 수 있는 annotated tag가 적합하다. git tag -a v1.0.0 -m "Release 1.0.0"이 기본 형태다. git describe 명령도 annotated tag를 기준으로 동작하므로, CI/CD 파이프라인에서 버전을 자동 생성할 때 annotated tag가 필수인 경우가 많다.

tag는 자동으로 원격에 올라가지 않는다 — release 절차에 push 단계를 명시해야 한다

git push origin main을 실행해도 tag는 원격으로 전송되지 않는다. tag를 공유하려면 git push origin v1.0.0처럼 명시적으로 push하거나, git push origin --tags로 모든 tag를 한 번에 전송해야 한다. 팀 release 절차에 tag push 단계가 빠지면 로컬에만 tag가 있는 상태가 생기고, 다른 팀원이 해당 기준점에 접근할 수 없다. CI/CD 파이프라인에서 tag push 이벤트를 트리거로 배포를 시작하는 경우라면, tag를 원격에 올리지 않으면 배포 자체가 시작되지 않는다.

tag 기반 버전 전략이 협업과 운영에 가져오는 실질적 이점

SemVer(Semantic Versioning) 기반의 tag(v1.2.3)를 일관되게 붙이면 changelog 생성, 배포 패키지 빌드, GitHub/GitLab의 Release 페이지 연동이 모두 자동화하기 쉬워진다. git log v1.1.0..v1.2.0 --oneline으로 두 버전 사이의 커밋 목록을 바로 뽑을 수 있어 release note 작성도 빨라진다. 또한 hotfix를 배포한 뒤 tag를 붙이는 습관은 "이 수정이 어느 버전부터 반영됐는가"를 추적하는 기반이 된다.

선택 기준

주의할 점