버전은 MAJOR.MINOR.PATCH 세 자리로 구성됩니다.
| 자리 | 올리는 경우 |
|---|---|
| MAJOR | 기존 사용법을 깨는 호환성 없는 변경 |
| MINOR | 기존 사용법은 유지한 채 기능 추가 |
| PATCH | 기능 변경 없이 버그만 수정 |
세 자리 중 하나를 올리면 그 오른쪽 자리는 0 으로 되돌립니다. 1.3.2 에서 기능을 추가하면 1.4.0 이 됩니다.
커밋 메시지 제목을 <타입>(<범위>): <설명> 형식으로 통일하면 기계가 종류를 구분할 수 있습니다. 범위는 생략 가능합니다.
| 타입 | 의미 |
|---|---|
feat |
새 기능 |
fix |
버그 수정 |
docs |
문서만 변경 |
ci |
파이프라인·워크플로 설정 변경 |
chore |
빌드·릴리스 등 잡무 커밋 |
호환성을 깨는 변경은 타입 뒤에 ! 를 붙이거나(feat!:), 본문에 BREAKING CHANGE: 줄을 추가해 표시합니다.
| 커밋에 있으면 | 올리는 자리 |
|---|---|
BREAKING CHANGE 또는 타입 뒤 ! |
MAJOR |
feat |
MINOR |
fix |
PATCH |
docs·ci·chore 뿐 |
올리지 않음 |
가장 큰 변경 하나만 적용합니다. feat 과 fix 가 섞여 있으면 MINOR 만 올립니다. 01_release.sh 의 bump_type 함수가 이 표를 그대로 grep -E 로 구현합니다(예제 1 참고).
이전 태그와 HEAD 사이 커밋 제목을 git log --pretty=format:'%s' <이전태그>..HEAD 로 뽑고, feat·fix 로 시작하는 줄만 grep 으로 골라 각각 Features·Fixes 절에 넣습니다. docs·ci·chore 커밋은 체인지로그에 나타나지 않습니다.
이렇게 만든 절을 CHANGELOG.md 맨 위, 제목 바로 아래에 끼워 넣으면 최신 릴리스가 항상 먼저 보입니다. 이 형식을 Keep a Changelog 라고 부릅니다.
새 버전 번호가 정해지면 VERSION 파일과 CHANGELOG.md 를 함께 고쳐 chore(release): vX.Y.Z 커밋을 만듭니다. 이 커밋은 타입이 chore 라 다음 릴리스의 체인지로그 계산에서는 제외됩니다.
04-build-artifact 레슨에서 다룬 VERSION 파일과 매니페스트의 Implementation-Version 이 이 커밋 이후 값과 같아야 빌드 산출물과 릴리스 번호가 어긋나지 않습니다.
릴리스에는 경량 태그(git tag v1.1.0, 메시지 없음)가 아니라 주석 태그를 씁니다. git tag -a v1.1.0 -m "Release v1.1.0" 처럼 메시지·작성자·날짜가 별도 객체로 남아 릴리스 이력 자체가 됩니다. 태그 이름은 항상 v 로 시작하는 형식(v1.1.0)으로 통일합니다.
GitHub Actions 워크플로 파일에 아래처럼 적으면 v 로 시작하는 태그가 push 될 때만 릴리스 잡이 실행됩니다.
on:
push:
tags:
- 'v*'일반 커밋 push 로는 이 워크플로가 돌지 않습니다. git push origin v1.1.0 처럼 태그를 따로 push 해야 트리거됩니다.
태그 push 로 워크플로가 끝나면 GitHub 저장소의 Releases 화면에 새 항목이 생깁니다. 실제로는 아래처럼 보입니다.
Releases · v1.1.0
제목: v1.1.0 / 본문: CHANGELOG.md 의 해당 절 내용
Assets: app-1.1.0.jar, app-1.1.0.jar.sha256본문은 CHANGELOG.md 의 새 절을 그대로 복사하고, Assets 에는 04-build-artifact 의 jar 와 체크섬 파일을 첨부합니다. 인터넷이 막힌 환경에서는 사내 Nexus 나 공유 폴더에 같은 파일을 올립니다.
release-please 는 커밋을 분석해 "Release PR" 을 자동으로 만드는 도구입니다. 이 PR 은 VERSION·CHANGELOG.md 변경만 담고 있고, 사람이 병합하면 그때 태그와 Release 가 만들어져 병합 전에 체인지로그를 한 번 더 확인할 수 있습니다.
semantic-release 는 사람의 병합 없이 커밋만 보고 버전·체인지로그·태그·Release 를 한 번에 만드는 완전 자동 도구입니다. 이번 레슨의 bump_type·gen_changelog 함수가 하는 일을 라이브러리로 대신한다고 보면 됩니다. release-please 는 "PR 로 확인 후 자동", semantic-release 는 "바로 자동" 이라는 차이로 구분합니다.
정식 릴리스 이후 급한 버그가 나오면 최신 main 이 아니라 배포된 태그에서 브랜치를 만들어 수정합니다. main 에는 아직 나가지 않은 기능 커밋이 섞여 있을 수 있기 때문입니다.
핫픽스 브랜치에서 PATCH 버전을 올려 먼저 배포하고, 같은 수정 커밋을 git cherry-pick 으로 main 에도 반영해 다음 정기 릴리스에 포함시킵니다.
커밋 쌓기(feat/fix/docs/ci/chore)
-> bump_type 으로 이전 태그 이후 커밋 판정
-> next_version 으로 다음 버전 계산
-> CHANGELOG.md 갱신 + VERSION 갱신 커밋(chore(release))
-> 주석 태그 생성 후 push
-> 태그 push 가 release.yml 워크플로 트리거
-> GitHub Release 에 체인지로그·산출물 게시