01
커밋 타입은 의미에 맞게 선택
제안 목록은 허용 목록이 아닙니다. 팀에서 정한 다른 명사를 직접 입력할 수 있고 대소문자도 유지됩니다. 기능 추가와 버그 수정 중 무엇에 해당하는지는 코드와 요구 사항을 아는 사용자가 결정해야 합니다.
Git & Version Control
커밋 메시지 생성기
필드를 조합하거나 완성된 메시지를 검증하세요. 모드를 바꿔도 각 초안은 유지됩니다.
커밋 메시지 생성기
메시지 입력
일반적인 타입 제안이며 사용자 정의 타입도 입력할 수 있습니다.
Refs: #42 또는 Closes #42로 시작하세요. 다음 일반 줄은 앞선 값의 연속입니다.
메시지 결과
메시지는 이 브라우저에서 처리합니다. 저장소 접근이나 네트워크 요청은 없습니다.
출력 옵션
Conventional Commits 1.0.0 구조를 검사합니다. 프로젝트 정책이나 50/72자 제한은 적용하지 않습니다. 최대 20,000 UTF-16 단위입니다.
설명이나 완성된 메시지를 입력하세요.
커밋 메시지 생성기는 커밋 메시지 작성 중 짧은 제목에 배경 설명이 섞이거나 호환성 단절 선언이 빠지는 일을 줄여 줍니다. 필드로 작성한 내용과 기존 메시지를 검증하는 초안을 따로 보관하므로 비교를 위해 입력을 지울 필요가 없습니다. 결과는 문장이 선언하는 의미를 보여 줄 뿐 실제 코드의 변경 내용을 대신 판단하지 않습니다.
커밋 메시지 생성기로 선언을 확인하는 이유
제목과 본문을 구분하기
커밋 메시지 생성기는 타입, 적용 범위, 설명을 한 줄로 조합하고 본문과 꼬리말 사이에 빈 줄을 넣습니다. 범위에는 괄호가 붙고 본문의 내부 문단은 유지됩니다. 다른 곳에서 작성한 메시지는 검증 모드에 넣어 확인하며 기존 작성 필드로 자동 변환하지 않습니다.
단절적 변경 선언 드러내기
일반적인 feat는 minor 의도를 나타내지만 ! 또는 유효한 BREAKING CHANGE 꼬리말이 있으면 major 선언이 우선합니다. 화면에서 이 차이를 확인할 수 있습니다. 설명에 호환성이라는 단어가 나온다는 이유만으로 단절을 추정하거나 실제 버전 번호를 계산하지는 않습니다.
구분과 실행 시점 확인
02
꼬리말의 이어지는 줄 확인
Refs: #42 또는 Closes #42처럼 토큰과 구분자로 시작합니다. 다음 일반 텍스트 줄은 앞선 값의 연속이며 새 유효 토큰이 나오면 다음 항목이 됩니다. 자유로운 본문과 명시적 꼬리말을 서로 다른 필드에 작성하세요.
03
자동 처리와 수동 실행 전환
자동 처리는 마지막 수정 후 350ms 뒤 실행됩니다. 끄면 작업 버튼이나 Ctrl/Cmd + Enter를 사용합니다. 입력 또는 ! 옵션이 바뀌는 즉시 이전 결과의 복사와 다운로드가 막히며 새 검사가 끝나야 다시 사용할 수 있습니다.
제목부터 여러 줄 꼬리말까지
언어와 사용자 정의 타입 유지
설명과 본문은 한국어로 작성할 수 있습니다. FEAT와 feat는 같은 변경 의도로 해석하지만 결과의 원래 표기는 유지합니다. 제목 글자 수는 표시만 하며 50자나 72자를 넘는다는 이유로 잘라 내거나 오류를 내지 않습니다.
완성된 메시지의 위치별 진단
검증 모드는 제목, 필수 빈 줄, 인식 가능한 꼬리말 구조를 확인합니다. 오류에는 행과 열이 있으며 편집기에서 해당 행을 강조합니다. 본문에 있는 URL이나 일반적인 콜론 문장을 무조건 잘못된 꼬리말로 취급하지 않습니다.
두 가지 호환성 단절 표시
!는 타입 또는 범위 뒤의 콜론 바로 앞에 붙입니다. 이것만으로도 선언이 되므로 별도 꼬리말을 강제하지 않습니다. BREAKING CHANGE: 설명과 BREAKING-CHANGE: 설명도 지원하며 이 특별한 토큰은 대문자여야 합니다.
구조 검사와 저장소 정책의 차이
- 팀의 정책을 대신 검사하지 않음
- 성공 결과는 commitlint나 저장소 훅을 통과한다는 보장이 아닙니다. 설정 파일, 타입 허용 목록, 소문자나 명령형 규칙을 읽지 않습니다. 코드가 실제로 수정되었는지, 올바른 타입을 골랐는지도 알 수 없습니다.
- 한 메시지와 명시적인 크기 제한
- 최대 20,000 UTF-16 단위이며 조합된 구두점과 빈 줄도 포함합니다. 초과하면 자르지 않고 거부합니다. CRLF와 CR은 LF로 바뀌고 작성 시 본문과 꼬리말의 양 끝 개행만 제거합니다. 내부 문단과 공백은 그대로 남습니다.
- 꼬리말 후보를 읽는 기준
- 원문에서는 빈 줄 뒤의 유효 토큰으로 꼬리말 구역을 시작합니다. 따라서 Note: text는 꼬리말일 수 있지만 콜론이 포함된 임의 문장은 본문으로 남습니다. 전용 꼬리말 필드의 첫 줄은 올바른 토큰과 값을 가져야 합니다.
- 저장소 실행과 배포 자동화 제외
- Git 실행, 이력 수정, diff 가져오기, 셸 명령 생성, AI 작성, 기록 저장이나 공유 URL은 제공하지 않습니다. major, minor, patch는 선언 의도이며 실제 버전 계산이 아닙니다. 다른 타입의 암묵적 영향과 revert 상쇄도 계산하지 않습니다.
- 교체는 확인한 다음 적용
- 예제와 비우기는 현재 모드에만 적용됩니다. 내용이 있으면 먼저 교체 내용과 UTF-16 단위 수를 검토합니다. 적용 후 한 번 되돌리기로 입력, ! 옵션, 결과를 함께 복구할 수 있습니다. 원문을 통과시키기 위한 자동 수정은 하지 않습니다.
커밋 메시지 생성기 질문
커밋 제목에서 타입은 대문자로 쓰나요 소문자로 쓰나요?
둘 다 허용됩니다. 팀 내에서 일관된 표기를 정하면 좋지만 검사기는 타입의 대소문자를 구분하지 않고 원문을 보존합니다. 단, BREAKING CHANGE와 BREAKING-CHANGE 꼬리말 토큰에는 대문자가 필요합니다.
커밋이 커밋 타입 중 하나 이상에 해당하는 경우 어떻게 해야 하나요?
가능하면 목적이 다른 변경을 별도 커밋으로 나누세요. 이 도구의 한 메시지에는 타입 하나만 있습니다. 본문으로 배경을 설명할 수 있지만 feat를 골랐다는 사실이 모든 코드 변경을 정확히 분류했다는 뜻은 아닙니다.
이것이 SemVer와 어떤 관련이 있나요?
fix는 patch, feat는 minor, ! 또는 유효한 호환성 단절 꼬리말은 major 의도를 나타냅니다. 단절 선언이 타입보다 우선합니다. 현재 버전이나 배포 이력을 모르므로 실제 다음 버전 번호는 계산하지 않습니다.
실수로 잘못된 커밋 타입을 사용하면 어떻게 해야 하나요?
아직 초안이면 타입을 수정하고 다시 검사하세요. feet 같은 오타도 사용자 정의 타입으로는 구조상 유효할 수 있습니다. 이미 만든 커밋의 amend나 rebase는 별도의 저장소 작업이며 이 페이지에서는 실행할 수 없습니다.
Conventional Commits은 revert commits을 어떻게 다루어야 하나요?
명세는 구체적인 되돌리기 동작을 도구 작성자에게 맡깁니다. revert 타입과 Refs 꼬리말로 대상을 설명할 수 있습니다. 이 검사기는 이전 변경의 영향을 빼거나 되돌린 뒤의 릴리스 버전을 결정하지 않습니다.
확인할 메시지 형식이 있나요?