Versioning Basics: Git tag란 무엇인가
TOC
Git tag란 무엇인가
Git tag는 특정 commit에 사람이 읽을 수 있는 이름을 붙이는 기능이다. 예를 들어 v2.4.1이라는 tag는 해당 릴리스에 포함된 정확한 commit을 가리킨다.
commit hash만으로도 소스 상태를 식별할 수 있지만, 긴 hash는 사람이 읽고 기억하기 어렵다. tag를 사용하면 “2.4.1 릴리스의 소스”처럼 의미 있는 이름으로 동일한 상태를 찾을 수 있다.
commit a13f9c2...
↑
v2.4.1
Branch와 tag의 차이
Branch와 tag는 모두 commit을 가리키지만 목적이 다르다. Branch는 새로운 commit이 추가되면 가리키는 위치가 계속 이동한다. 반면 tag는 특정 시점의 commit을 기록하고, 릴리스 이력의 기준점으로 남긴다.
main branch → A → B → C → D
↑
v2.4.1 tag
따라서 개발 중인 코드를 가리키는 branch와 공개된 버전을 가리키는 tag를 같은 방식으로 다루면 안 된다. branch는 다음 작업을 이어가기 위한 포인터이고, tag는 이미 결정된 상태를 찾기 위한 포인터다.
릴리스 tag가 필요한 이유
릴리스 tag는 소스 코드와 릴리스를 연결하는 기준점이다. 운영 장애가 발생했을 때 어떤 commit에서 artifact가 만들어졌는지 확인할 수 있고, 같은 commit을 다시 빌드해 문제를 재현하거나 이전 버전으로 복구할 수 있다.
tag는 commit만 가리키는 데서 끝나지 않는다. 릴리스 노트, 빌드 결과물, 배포 기록, commit SHA와 함께 관리해야 “무엇을 배포했는가?”라는 질문에 답할 수 있다.
릴리스 tag 불변 원칙
한 번 외부에 공개한 v2.4.1 tag를 나중에 다른 commit으로 옮기면 안 된다. 같은 이름이 서로 다른 소스 상태를 가리키게 되어, 이전 artifact를 재현할 수 없고 배포 기록도 신뢰할 수 없게 된다.
릴리스에 문제가 있으면 기존 tag를 수정하지 말고 v2.4.2와 같은 새 버전을 만들어야 한다. tag의 이름과 대상 commit을 고정하는 것은 버전관리의 최소한의 신뢰 경계다.
Conclusion
Git tag는 특정 commit에 릴리스 이름을 붙여 소스 상태를 고정하는 식별자다. 일관된 이름 규칙을 사용하고 공개된 tag를 변경하지 않으면, 릴리스를 추적·재현·복구할 수 있는 기준점을 확보할 수 있다.
다음 글에서는 commit, build, artifact가 각각 무엇을 의미하고 어떻게 연결되는지 살펴본다.