Conventional Commit 메시지 빌더
타입, 스코프, 호환성 깨짐, 푸터가 포함된 Conventional Commits 메시지를 브라우저에서 만듭니다.
사용법
- 커밋 타입(feat, fix 등)과 선택적 스코프를 고릅니다.
- 짧은 설명을 작성하고 필요하면 본문이나 푸터를 추가합니다.
- 해당하면 호환성 깨짐을 켜고 생성된 메시지를 복사합니다.
자세한 설명
펼치기접기
타입, 선택적 스코프, 설명, 본문, 푸터를 채우면 Conventional Commits 1.0.0을 따르는 메시지가 만들어집니다. 순서에 맞게 조립되고 헤더·본문·푸터 사이에 규격이 요구하는 빈 줄도 들어갑니다. feat와 fix부터 docs, refactor, perf, test, build, ci, chore, revert까지 흔히 쓰는 열한 가지 타입을 모두 제공합니다. 브레이킹 체인지를 표시하면 관례의 양쪽을 한 번에 처리합니다. 타입이나 스코프 뒤에 느낌표를 붙여 사람이 한눈에 알아보게 하고, 릴리스 도구가 메이저 버전을 올릴 때 읽는 BREAKING CHANGE 푸터도 함께 씁니다. 모든 처리는 브라우저에서 이루어지며 아무것도 업로드되지 않습니다.
자주 묻는 질문
어떤 형식을 따르나요?
Conventional Commits 1.0.0 사양입니다: type(scope)!: description, 그 뒤에 빈 줄로 구분된 선택적 본문과 푸터가 옵니다.
호환성 깨짐은 어떻게 표시되나요?
호환성 깨짐을 켜면 타입/스코프 뒤에 !가 추가되고, 설명을 입력하면 BREAKING CHANGE: 푸터가 추가됩니다.
푸터에는 무엇이 들어가나요?
이슈 참조 같은 메타데이터입니다 — 예: Closes #123 또는 Reviewed-by: 이름. 한 줄에 푸터 하나씩 입력하세요.
제 입력이 어딘가로 전송되나요?
아니요. 메시지는 전적으로 브라우저에서 조립되며 아무것도 업로드되지 않습니다.
고른 타입이 배포 버전에 영향을 주나요?
릴리스 도구가 그것을 읽도록 연결되어 있을 때만 그렇습니다. 통상적인 관례는 fix가 패치, feat가 마이너 릴리스를 만들고 브레이킹 체인지가 메이저를 올리는 것이지만, 그 대응 관계는 메시지 자체가 아니라 semantic-release나 changesets 안에 있습니다.
느낌표가 이미 알려 주는데 왜 푸터에 BREAKING CHANGE를 또 쓰나요?
읽는 대상이 다르기 때문입니다. 느낌표는 로그를 훑는 사람이 보는 것이고, 푸터는 도구가 파싱하는 것이며 무엇이 깨졌고 대신 무엇을 써야 하는지 설명할 수 있는 유일한 자리입니다. 규격은 둘 중 하나만 써도 되지만, 둘 다 쓰는 편이 가장 명확합니다.
관련 도구
Semver 도구 (파서·비교기·범프)
두 시맨틱 버전 동시 파싱·비교·범프, ^x.y.z·~x.y.z가 실제 어디까지 매치하는지 보여주는 범위 확장기 포함.
개발
HMAC 생성기 (SHA-1·256·384·512)
Web Crypto로 HMAC 서명 계산 — 웹훅 페이로드 서명, API 요청 검증, hex 또는 base64.
개발
JSON to Protobuf 스키마 변환기 (proto3)
JSON 객체를 타입 지정 필드와 중첩 메시지를 갖춘 proto3 .proto 스키마로 브라우저에서 변환합니다.
개발
.mailmap 테스터
.mailmap과 작성자 신원 목록을 붙여 넣으면 각 신원이 무엇으로 바뀌는지, 어느 줄이 그렇게 만들었는지, 누가 하나로 합쳐지는지 보여 줍니다.
개발
Git 객체 ID 계산기 (hash-object)
blob·tree·commit·tag의 git 객체 ID를 SHA-1과 SHA-256으로 계산하고, git이 해시하는 헤더와 루스 객체 경로까지 보여줍니다.
개발
.gitignore 생성기
사용하는 언어·프레임워크·에디터·OS를 체크 → 새 리포지토리에 바로 넣을 수 있는 통합 .gitignore.
개발