Tag와 Release Note를 이용해보자
최근 진행하는 프로젝트가 Release 되고, 그 종류도 많아짐에 따라 Tag와 Release Note 작성에 관한 업무가 할당되었다. 👀
사실 제대로 써보지 않은 Github 기능이라 어떤 Release Note가 좋은 건지 또 어떻게 만들면 되는거지 감을 잡아가는 중이다.
그래서 이번 글에서는 해당 내용을 정리해보고자 한다.
👀 다른 프로젝트의 Release Note 살펴보기
어떤 Release Note가 좋은 Release Note인지 알아보기 위해서 다른 깃허브 프로젝트를 살 했다.
어리고 한가지 내린 결론은 생각했던 것처럼 엄청 거창한 건 아니라는 거다. (공식 블로그 글처럼 각잡고 써야하나 싶기도 했었기에…)
찾아봤던 release note는 아래와 같다.
⭐ Semantic Versioning
다른 글에서도 한 번 다뤘지만 시멘틱 버저닝에 대해서 다시 정리해보자.
형식은 다음과 같다.
1
MAJOR.MINOR.PATCH
MAJOR 버전: 기존과 호환되지 않는 API 변경이 있을 때 증가
MINOR 버전: 이전 버전과 호환되면서 기능을 추가할 때 증가
PATCH 버전: 이전 버전과 호환되는 버그 수정이 있을 때 증가
이를 적용한 예시는 다음과 같다.
1
2
3
4
v1.0.0 첫 정식 릴리즈
v1.1.0 로그인 기능 추가
v1.1.1 로그인 버그 수정
v2.0.0 API 구조 변경 (호환 깨짐)
🐾 태그를 만드는 순서
태그는 이 커밋이 이 버전임을 나타내는 이름표이기 때문에 순서는
- 커밋
- 태그 생성
으로 진행한다.
전체적인 명령어 흐름은 다음과 같다.
1
2
3
4
5
git add .
git commit -m "feat: 로그인 기능 추가"
git tag v1.0.0
git push origin main
git push origin v1.0.0
annotated tag
위에서 만든 태그는 경량 태그로 커밋에 단순 숫자 이름을 붙이는 거라면, annotated tag는 ‘설명’이 추가된 태그라고 할 수있다.
명령어는 다음과 같다.
1
git tag -a v1.0.0 -m "first release"
명령어 차이
1
git tag <tagname>
- 가장 기본 태그 (lightweight tag) 생성
- 메시지 없음
1
git tag -a <tagname>
- annotated tag 생성
1
git tag -a <tagname> -m "message"
- annotated tag 생성
- 메시지를 바로 같이 저장
annotated tag는 메시지를 포함한 태그라서 git show로 내용을 볼 수 있어 단순 숫자 태그보다 실무에서 자주 사용되는 형태이다.
🌙 Github를 이용한 자동 릴리즈 노트 만들기
깃허브를 통해 자동으로 릴리즈 노트를 만들 수 있다. 이때 릴리즈 노트는 PR을 기준으로 만들어짐에 주의한다.
전체적인 흐름은 다음과 같다.
- 사용자 커밋
- PR 생성 & merge
- Release 생성
- Releases → Draft a new release
- tag 입력
- Generate release notes 클릭
이를 테스트해보고자 평소 사용하던 깃허브 연습용 레포를 활용해보았는데, 이때 느낀 점은 PR 제목을 결과물 기준으로 작성해야 깔끔하게 릴리즈 노트가 작성된다는 거였다.
커밋이 여러개인 경우 PR 생성할때 자동으로 생성되는 이름을 활용하면 릴리즈 노트에서는 “그래서 무엇을 고쳤다는거지?” 라는 의문이 들 수밖에 없었기 때문이다.
즉 애초에 PR을 생성할 때 title을
feat: 로그인 기능 추가
로 정확하게 남겨놓으면 자동으로 생성된 release note에서도 해당버전에서 로그인 기능이 추가되었음을 정확하게 인지할 수 있었다.