17강. 태그, Release, 버전 관리

?1. 이번 강의에서 해결할 문제

“지난주 버전”처럼 모호한 표현으로는 배포한 코드를 다시 찾기 어렵습니다. 검증된 커밋에 변경되지 않는 버전 이름을 붙이고 릴리스 노트를 남깁니다.

✓2. 학습 목표

✓이 강의를 마치면

• 브랜치와 태그의 이동성 차이를 설명합니다.
• annotated tag를 만들고 원격에 게시합니다.
• Semantic Versioning 기준으로 버전을 선택합니다.

◇3. 핵심 개념

브랜치는 새 커밋마다 이동하지만 태그는 특정 커밋을 가리키는 고정된 이름입니다. v1.2.3은 보통 major.minor.patch를 뜻합니다. 호환되지 않는 변경은 major, 기능 추가는 minor, 버그 수정은 patch를 올립니다.

§4. 단계별 명령어와 예시

대상 저장소: C:\dev\git-learning-site

PowerShell

Set-Location C:\dev\git-learning-site
git switch main
git pull --ff-only
npm.cmd run build
git status
git tag -a v1.0.0 -m "First stable learning site"
git show v1.0.0 --stat
git push origin v1.0.0
git tag --list "v*" --sort=-version:refname

GitHub 저장소의 Releases → Draft a new release에서 기존 v1.0.0 태그를 선택하고 변경 내용과 실행 방법을 적습니다. UI가 바뀌면 GitHub 공식 Releases 문서를 확인합니다.

→5. 명령어가 동작하는 이유

annotated tag는 대상 커밋 외에 작성자, 날짜, 메시지를 별도 객체로 저장합니다. 일반 git push는 태그를 자동 전송하지 않으므로 태그 이름을 명시합니다. Release는 GitHub가 태그에 설명과 첨부 파일을 연결한 배포 페이지입니다.

!6. 자주 하는 실수와 안전한 해결법

!자주 하는 실수

• 빌드 실패 커밋에 태그: 먼저 main 최신화, 테스트, status 확인을 완료합니다.
• 공개 태그를 삭제·재사용: 사용자가 다른 코드를 같은 버전으로 받게 됩니다. 수정은 새 patch 버전으로 냅니다.
• 모든 태그를 무심코 push: git push --tags보다 이번 태그 이름을 명시합니다.

✎7. 직접 실습

✎직접 실습

1. 검증된 연습 커밋에 v0.1.0 annotated tag를 만듭니다.
2. git show로 대상과 메시지를 확인한 뒤 push합니다.
3. GitHub Release 초안을 만들고 변경점 세 줄을 작성합니다.

?8. 이해 점검 질문 3개

?이해 점검

1. 브랜치와 태그는 새 커밋을 만들 때 어떻게 다르게 움직이나요?
2. 기능을 호환되게 추가했다면 보통 어느 버전을 올리나요?
3. annotated tag를 만드는 옵션은 무엇인가요?

■9. 핵심 요약

■핵심 요약

태그는 검증된 커밋의 변하지 않는 버전 이름이고 Release는 배포 설명입니다. 빌드와 상태 확인 후 태그를 만들고, 공개된 버전은 재사용하지 않습니다.