changelog 생성기

아직 아무것도 없습니다. 위에 몇 줄을 붙여넣고 생성을 누르세요.

각 줄에 대해 하는 일

규칙은 의도적으로 단순하고 눈에 보이도록 되어 있어, 추측하는 대신 출력을 예측할 수 있습니다:

1. Conventional commit은 유형별로 그룹화됩니다. `feat`는 '새 기능'이 되고, `fix`는 '수정'이 되고, `perf`는 '개선'이 됩니다. 콜론 앞의 `!`나 BREAKING CHANGE 마커는 유형과 관계없이 해당 줄을 '호환성이 깨지는 변경 사항'으로 옮깁니다.
2. conventional commit이 아닌 것은 첫 단어로 정렬됩니다. Add, Added, Introduce, Support는 '새 기능'이 되고, Fix, Fixed, Resolve는 '수정'이 되고, Improve, Update, Speed, Optimise는 '개선'이 되고, Remove, Removed, Drop, Deprecate는 '삭제'가 됩니다. 나머지는 직접 정렬할 수 있도록 '기타'에 들어갑니다.
3. 노이즈는 제거됩니다: 끝에 있는 풀 리퀘스트 번호, `Merge pull request ...` 줄, 괄호 안의 범위, 그리고 conventional 유형 접두사 자체. 남은 문장은 대문자로 시작합니다.
4. 필터가 켜져 있으면 `chore`, `ci`, `test`, `build`, `style`, `refactor` 줄이 의존성 업데이트처럼 보이는 것과 함께 제외됩니다. 이것이 사람들이 읽는 changelog와 읽기를 멈추는 changelog의 유일하고 가장 큰 차이입니다.

할 수 없는 것

커밋 메시지의 내용이 아니라 형태를 다시 씁니다. 커밋이 `fix: race in MembershipCache.resolve()`라고 말한다면, 나오는 것도 그것이며, 여전히 사용자의 경험이 아니라 여러분의 코드에 대한 문장입니다. 'race in MembershipCache'를 '초대된 멤버가 더 이상 빈 대시보드를 보지 않음'으로 바꾸려면 그 변경이 무엇을 했는지 알아야 하며, 이는 생성기가 커밋 제목 줄에서 추론할 수 없는 부분입니다.

따라서 출력을 첫 단계로 취급하세요: 구조는 올바르고, 그룹화도 올바르며, 내부 노이즈는 이미 사라졌지만, 표현은 여전히 여러분이 고쳐야 합니다.

자주 묻는 질문

제가 붙여넣은 것이 어딘가로 업로드되나요?

아니요. 생성기는 이 페이지의 스크립트이며, 텍스트는 절대 브라우저를 떠나지 않고, 생성을 누를 때 저희에게 요청이 가지 않습니다. 네트워크 탭을 열어서 확인할 수 있습니다.

conventional commits를 사용해야 하나요?

아니요. 관례를 따르는 줄은 더 정확하게 그룹화되며, 나머지는 앞의 동사로 대체됩니다. 일반적인 문장 형태의 커밋 메시지가 있는 저장소도 여전히 사용 가능한 초안을 만들어냅니다.

제 저장소에서 이것을 자동으로 얻으려면 어떻게 하나요?

일회성 사용에는 `git log --pretty=format:%s v1.2.0..HEAD`가 이것이 기대하는 입력을 정확히 제공합니다. 지속적인 용도로는 git-cliff와 github-changelog-generator 둘 다 커밋 히스토리에서 CI에서 changelog 파일을 구축하며, Changeloop는 병합된 풀 리퀘스트마다 사용자 지향 항목을 작성하여 검토를 위해 보관합니다.

왜 제 출력이 '기타'로 가득한가요?

앞의 동사가 알려진 어떤 것과도 일치하지 않았으며, 이는 보통 커밋 제목이 명사나 티켓 ID로 시작한다는 것을 의미합니다. 생성하기 전에 박스에서 수정하거나, 나중에 '기타' 줄을 수동으로 옮기세요.

더 읽어보기: conventional commits에서 changelog로, 커밋 형식이 무엇을 가져다주고 어디서 멈추는지에 대해.