Git히스토리와 복구

tag와 release 기준점

특정 커밋을 버전 기준점으로 남기는 tag가 브랜치와 무엇이 다르고, release 흐름에서 어떻게 쓰이는지 정리합니다.

마지막 수정 2026년 3월 22일

기본 패턴

text
git tag -a v1.0.0 -m "Release 1.0.0"
git push origin v1.0.0

설명

  • 브랜치는 계속 움직이는 작업선이라면, tag는 특정 커밋을 가리키는 고정된 기준점입니다. 그래서 배포 버전, 중요한 마일스톤, 백업 기준을 남길 때 특히 유용합니다.
  • v1.0.0 같은 버전 태그를 붙여 두면, 나중에 "그때 실제로 배포된 코드는 무엇이었는가"를 훨씬 쉽게 되짚을 수 있습니다. 운영 사고나 회귀 분석에서 큰 차이를 만듭니다.
  • lightweight tag와 annotated tag가 있지만, release 용도라면 보통 메시지와 메타데이터를 남길 수 있는 annotated tag가 더 적합합니다.
  • 중요한 점은 tag도 자동으로 원격에 올라가지 않는다는 것입니다. 커밋 push와 tag push는 별도 동작이므로, release 절차에는 tag 전송까지 포함되어야 합니다.
  • 이 주제의 핵심은 히스토리를 "작업 흐름"으로만 보지 않고, "배포 기준점" 관점으로도 보는 것입니다. 개발과 운영 사이를 이어 주는 가장 가벼운 도구 중 하나가 tag입니다.

빠른 정리

요소의미
브랜치움직이는 작업선
tag고정된 커밋 기준점
annotated tag메시지와 메타데이터를 가진 tag
git push origin <tag>특정 tag를 원격에 전송
잘 맞는 곳배포 버전, 릴리스 기준점

주의할 점

커밋을 push했다고 tag까지 같이 올라가는 것은 아닙니다. release 기준점을 팀이 공유해야 한다면 tag를 별도로 push하는 단계까지 절차에 넣는 편이 안전합니다.

참고 링크

2 sources