release-notes은(는) 무엇을 하나요?
Git 히스토리를 사람이 실제로 읽고 싶어할 만한 릴리스 노트로 변환합니다.
기능
- 두 참조(태그, 브랜치,
HEAD) 사이의 커밋 비교 - 변경 유형별 그룹화: 기능, 수정, 주요 변경, 잡일
- Conventional Commit
!마커와BREAKING CHANGE:푸터에서 주요 변경 사항 감지 - 하이라이트 섹션 초안 작성 (사용자가 실제로 관심을 가질 3-5개 변경 사항)
- GitHub 릴리스에 바로 사용 가능한 마크다운 출력
사용법
# 다가오는 릴리스를 위한 노트 (마지막 태그 -> HEAD)
git log $(git describe --tags --abbrev=0)..HEAD --oneline
# 두 태그 사이
git log v1.2.0..v1.3.0 --pretty=format:'%h %s %b'
그런 다음 에이전트에게 요청: "이 커밋들로 v1.3.0 릴리스 노트를 작성해줘."
또는 GitHub CLI를 사용하여 바로 릴리스 초안으로:
# 태그 생성 후, diff로 릴리스 노트 초안 작성
git tag v1.3.0 && git push origin v1.3.0
gh release create v1.3.0 --generate-notes --draft
# 그런 다음 이 스킬로 생성된 노트를 다듬습니다
프로세스
1. 커밋 수집
git log <이전-태그>..<새-태그> --pretty=format:'%h|%s|%b|%an' --no-merges
저장소가 머지 기반 워크플로우를 사용하는 경우 머지 커밋은 별도로 포함하세요. 머지 제목은 개별 커밋보다 PR을 더 잘 요약하는 경우가 많습니다.
2. 각 커밋 분류
| 접두사 / 신호 | 섹션 |
|---|---|
feat, feat! | 기능 |
fix | 버그 수정 |
! 또는 BREAKING CHANGE: | ⚠️ 주요 변경 사항 (자체 섹션에도 나열됨) |
perf | 성능 |
docs, chore, ci, refactor, test | "기타"로 그룹화 또는 생략 |
Conventional 접두사가 없는 커밋: 메시지 내용으로 분류합니다. 모호한 경우, 조용히 생략하기보다는 "기타 변경 사항"에 넣습니다.
3. 하이라이트 초안 작성
소프트웨어 사용자에게 가장 중요한 3-5개 변경 사항을 선택합니다:
- 사용자가 알아차릴 새로운 기능
- 사용자가 조치해야 할 주요 변경 사항
- 널리 보고된 문제에 대한 수정
각 항목을 평범한 한 문장으로 작성합니다. 마케팅 형용사는 사용하지 않습니다.
4. 노트 작성
## v1.3.0
**하이라이트**
- ...
- ...
### ⚠️ 주요 변경 사항
- ...
### 기능
- ...
### 버그 수정
- ...
### 기타 변경 사항
- ...
**전체 체인지로그:** <이전-태그>...<새-태그>
5. 게시 전 검증
- 모든 주요 변경 사항이 ⚠️ 섹션에 마이그레이션 힌트와 함께 표시되는지 확인
- 내부 전용 잡일이 사용자 대상 기능으로 제시되지 않았는지 확인
- 저장소 관례에 따라 기여자 이름이 표시되었는지 확인
- 버전 번호가 태그와 일치하는지 확인
규칙
- 저장소에 기존 릴리스 노트 스타일이 있다면 따르세요. 일관성이 어떤 템플릿보다 중요합니다.
- 저장소가
gh release --generate-notes를 사용한다면, 그 출력을 시작 초안으로 사용하고 다듬으세요. 목록은 올바르지만 하이라이트는 잘못된 경우가 많습니다. - 커밋 범위에 없는 변경 사항을 임의로 만들지 마세요. 범위가 모호하면 추측하지 말고 어떤 참조를 비교할지 물어보세요.