Git 태그

tag

Git 에서 태그 (tag) 는 특정 커밋을 식별하기 위해 붙이는 일종의 이름표로 릴리즈나 특정 버전을 표시할 때 사용되어 프로젝트의 버전 관리와 릴리즈 관리를 체계적으로 할 수 있도록 돕는 중요한 도구입니다.

 

Git 태그는 경량 태그와 (Lightweight Tag) 주석 태그 (Annotated Tag) 두 가지 종류로 나눌 수 있습니다.

• 경량 태그 (Lightweight Tag)
  • 단순히 특정 커밋을 가리키는 포인터 역할입니다.
  • 추가적인 메타 데이터 (작성자, 날짜 등) 가 포함되지 않습니다.
  • 주로 내부적이거나 임시적으로 사용할 때 적합합니다.

git tag <tag-name>  # 현재 HEAD 가 가리키고 있는 커밋에 적용 (다른 브랜치에서도 해당 커밋에 자동 적용)

git tag <tag-name> <commit-hash>  # 특정 커밋에 경량 태그 추가

• 주석 태그 (Annotated Tag)
  • 메타 데이터 (작성자, 이메일, 날짜, 태그 메시지 등) 가 포함됩니다.
  • GPG 로 서명할 수도 있어 보안성이 더 높습니다.
  • 주로 공식 릴리즈에 사용됩니다.

git tag -a <tag-name> -m "tag message"  # 현재 HEAD 가 가리키고 있는 커밋에 적용되며 (다른 브랜치에서도 해당 커밋에 자동 적용) -m 옵션 생략시 태그 메시지 편집기 자동 실행

git tag -a <tag-name> <commit-hash> -m "tag message"  # 특정 커밋에 경량 태그 추가. -m 옵션 생략시 태그 메시지 편집기 자동 실행

주석 태그의 경우 작성자, 이메일, 날짜 등의 정보는 Git 설정 (git config) 의 사용자 정보에서 Git 이 자동으로 가져와 기록합니다. 하지만 태그 메시지는 사용자가 직접 입력해야 합니다.

 

하나의 태그는 하나의 커밋만 가리킬 수 있지만, 여러 태그가 같은 커밋을 가리키는 것은 가능합니다.

Git 태그 생성 및 관리를 사용자가 직접 할 수도 있지만 커밋 메시지를 기반으로 자동으로 태그 이름과 메시지를 생성해주고 관리에 도움을 주는 도구들이 있습니다.

여러가지 tag 관련 명령어

태그 확인

• 태그 확인

git tag

• 태그 검색

git tag --list "Glob Pattern"  # ex. git tag -l "v1.*"

태그 푸시

• 원격 저장소에 특정 태그 푸시

git push <remote-alias> <tag-name>

• 원격 저장소에 모든 태그 한 번에 푸시

git push <remote-alias> --tags

태그 삭제

• 로컬 태그 삭제

git tag -d <tag-name>

• 원격 태그 삭제

git push <remote-alias> --delete <tag-name>

브랜치 삭제와는 다르게 원격 태그 삭제가 로컬 태그 삭제에 영향을 주지 않습니다.

태그로 체크아웃

• 태그를 기준으로 특정 커밋으로 체크아웃

git checkout <tag-name>

태그 이름 작성 컨벤션

태그 이름을 작성하는 명확한 표준은 없지만 태그는 일반적으로 릴리즈 버전 관리와 관련된 경우가 많기 때문에 SemVer (Semantic Versioning) 의 규칙을 따르는 것이 가장 흔한 방식입니다. 보통 v 를 먼저 쓰고 이후에 SemVer 의 규격에 따라 버전 번호를 붙여줍니다.

SemVer 형식

SemVer 에서 규격하는 정식 버전 번호 (Release Version) 의 형식은 아래와 같습니다.

<MAJOR>.<MINOR>.<PATCH>

항목	의미	예시
MAJOR	호환되지 않는 변경이 포함된 경우 증가합니다.	1.0.0 -> 2.0.0
MINOR	기존과 호환되는 새로운 기능이 추가되었을 때 증가합니다.	1.0.0 -> 1.1.0
PATCH	기존과 호환되는 버그 수정 혹은 성능 개선이 있을 때 증가합니다.	1.0.0 -> 1.0.1

• MAJOR 가 증가하면: MINOR 와 PATCH 를 0으로 초기화
• MINOR 가 증가하면: PATCH 를 0으로 초기화
• PATCH 가 증가하면: 다른 숫자는 유지

SemVer 에는 정식 버전 번호 숫자를 반드시 1씩 증가시키라는 명시적인 규칙은 없으나 1씩 증가시키는것이 보편적입니다.

SemVer 확장

SemVer 에서는 릴리즈 버전 뒤에 선택적으로 프리 릴리즈 (Pre-release) 와 빌드 메타 데이터 (Builld Metadata) 를 포함할 수 있습니다. 버전 비교시에는 MAJOR.MINOR.PATCH-Pre-release 까지만 고려되며 Build Metadata 정보는 버전 비교에 영향을 미치지 않습니다.

MAJOR.MINOR.PATCH-<pre-release>+<build metadata>

 

프리 릴리즈와 빌드 메타 데이터는 선택적으로 올 수 있지만 위의 배치 순서는 반드시 지켜져야 합니다.

• 프리 릴리즈 (Pre-release)
  • 정식 버전 이전의 테스트용 버전
  • 형식: -<pre-release>
    • -<identifier>[.<number>]
  • identifier 로 alpha, beta, rc (release candidate) 등의 명칭이 주로 사용
    • alpha: 초기 개발 단계. 기능이 완전히 구현되지 않았거나 불안정한 상태.
    • beta: 주요 기능이 구현되었고 테스트 중인 상태. 안정성 개선 단계.
    • rc: 릴리즈 직전 버전. 안정성을 확인하는 최종 테스트 단계.
  • SemVer 에는 명칭 및 숫자 증감 등에 대한 규정은 없으나 프리 릴리스의 정렬 순서는 규정하고 있음
    • 알파벳 순서로 비교
      • ex. alpha -> beta -> rc
    • 동일한 이름에서는 숫자가 사전순으로 비교
      • ex. alpha.9 -> alpha.10
    • 프리 릴리즈 태그는 기본 릴리즈보다 우선 순위가 낮게 정렬
      • ex. v1.4.2-alpha.1 -> v1.4.2-alpha.2 -> v1.4.2-beta.1 -> v1.4.2-rc.1 -> v1.4.2
• 빌드 메타 데이터 (Build Metadata)
  • 빌드 정보를 추가적으로 명시
  • 형식: +<build metadata>
    • 케이스 형식에 대한 규정은 없으나 주로 kebab-case 사용
  • 주로 소프트웨어의 빌드나 배포 정보를 포함하지만 작성 형식, 내용, 숫자 포함 여부 등은 작성자 재량이며 SemVer 사양에 강제 사항은 없음
    • ex. v1.0.0+build.123, v1.0.0+exp.sha.5114f85, v1.0.0+release.2023.12.01, v2.1.3-beta.2+build.42
  • 빌드 메타 데이터는 버전 비교에 영향을 주지 않으며, 단순히 추가적인 정보를 나타내는 용도로만 사용
    
    • ex. v1.3.8-beta.3+build.42 와 v1.3.8-beta.3+build44 는 SemVer 에서 동일한 우선 순위의 버전으로 간주

SemVer 는 숫자 증감 및 프리 릴리즈 사용에 있어 유연성을 제공합니다. 중간에 버전을 건너 뛰어도 되며 프리 릴리즈가 어쩔때는 존재하지 않아도 문제되지 않습니다. 예를들면 어떤 프로젝트의 정식 릴리즈와 프리 릴리즈가 포함된 전체 버전 배포 히스토리가 v1.0.0 -> v1.0.1-alpha.4 -> v1.0.1-beta -> v1.0.1 -> v2.3.4-alpha.2 -> v3.4.5 와 같을때 이는SemVer 의 규칙에 완벽히 부합되며 문제되지 않습니다.

태그 메시지 작성 컨벤션

태그 메시지 작성 방식에 대한 엄격한 규정은 없으며, 팀 또는 프로젝트 내에서 규칙에 따라 일관성을 유지하는 것이 중요합니다. 보통은 해당 태그가 가리키는 릴리즈의 주요 변경 내용을 요약하는것이 일반적입니다. 아래 예시처럼 릴리즈 제목, 변경 내용 요약, 참조 링크와 같은 정보를 포함시킬 수도 있습니다.

릴리즈: v1.0.0

주요 변경 사항:
- 새로운 사용자 인증 시스템 추가.
- REST API 성능 개선.
- UI 디자인 업데이트.

버그 수정:
- 로그인 페이지에서 발생한 500 에러 수정 (#42).
- 잘못된 파일 업로드 문제 해결 (#56).