liminfoGit Commit Generator
Conventional Commits 스펙 기반 커밋 메시지 생성기
0/72 자
생성된 커밋 메시지
feat: Git Commit Generator 소개
Git 커밋 메시지 생성기는 개발자가 Conventional Commits 명세(conventionalcommits.org)를 따르는 잘 구조화된 커밋 메시지를 작성하도록 돕습니다. 11가지 커밋 타입 중 하나를 선택합니다 — feat(새 기능), fix(버그 수정), docs(문서), style(코드 형식), refactor(코드 재구성), test(테스트 추가/수정), chore(빌드/도구 변경), perf(성능 개선), ci(CI 설정), build(빌드 시스템), revert(커밋 되돌리기) — 그런 다음 괄호 안에 선택적 범위를 추가하고, 짧은 설명을 작성하며, 선택적으로 여러 줄 본문을 추가합니다. 도구는 모든 입력을 올바른 Conventional Commits 헤더 형식으로 포맷합니다: type(scope)!: description.
Conventional Commits는 시맨틱 버저닝(Semantic Versioning)과 직접 매핑되는 가벼운 커밋 메시지 규약입니다. feat 타입의 커밋은 마이너 버전을 올리고, fix 타입은 패치 버전을 올리며, BREAKING CHANGE 푸터나 타입/범위 뒤의 !가 있으면 메이저 버전을 올립니다. Breaking Change 체크박스를 활성화하면 헤더에 !가 추가되고 BREAKING CHANGE: 설명 푸터가 올바른 형식으로 추가됩니다. 이를 통해 standard-version, semantic-release, release-please 같은 자동화 도구의 changelog 생성 및 버전 업데이트를 지원하는 커밋 메시지를 손쉽게 생성할 수 있습니다.
범위 필드는 선택 사항이지만 모노레포와 대규모 코드베이스에서 강력히 권장됩니다. 일반적인 범위 값으로는 컴포넌트 이름(auth, api, ui), 패키지 이름, 기능 영역 등이 있습니다. 설명 필드는 문자 수를 추적하여(72자 제한 표시) 커밋 요약을 관례적인 제한 내에 유지합니다. 본문 필드는 변경 사항의 동기와 컨텍스트를 설명하는 여러 줄 텍스트를 허용하며, 몇 달 후 코드 히스토리를 검토할 때 특히 유용합니다.
주요 기능
- 11가지 커밋 타입: feat, fix, docs, style, refactor, test, chore, perf, ci, build, revert
- 괄호 안 선택적 범위 필드 — 예: feat(auth): OAuth2 로그인 추가
- 지나치게 긴 요약을 방지하는 설명 문자 카운터(72자 제한 표시)
- 상세 변경 컨텍스트와 동기 작성을 위한 여러 줄 본문 텍스트 영역
- Breaking Change 토글: 헤더에 ! 추가 및 BREAKING CHANGE: 푸터 자동 추가
- 최종 메시지를 실시간으로 확인할 수 있는 형식화된 코드 블록 라이브 미리보기
- 시각적 확인(복사됨! 피드백)이 있는 원클릭 클립보드 복사
- 100% 클라이언트 사이드 — 서버 요청 없음, 메시지가 브라우저 밖으로 전송되지 않음
자주 묻는 질문
Conventional Commits 명세란 무엇인가요?
Conventional Commits는 커밋 메시지에 구조화된 형식을 부여하는 규약입니다: type(scope)!: description. 도구가 자동으로 버전 업데이트(패치/마이너/메이저)를 결정하고 changelog를 생성할 수 있도록 커밋 히스토리를 기계 판독 가능하게 만들기 위해 만들어졌습니다. Angular, Vue, Nest.js 등 많은 프레임워크에서 기본으로 채택하고 있습니다.
feat와 fix 커밋 타입의 차이는 무엇인가요?
feat(기능)는 커밋이 최종 사용자가 관찰할 수 있는 새로운 기능이나 동작을 도입할 때 사용합니다. fix는 버그나 의도하지 않은 동작을 수정할 때 사용합니다. 이 구분은 시맨틱 버저닝에 영향을 미칩니다: feat는 마이너 버전 업(예: 1.2.0 → 1.3.0)을, fix는 패치 버전 업(예: 1.2.0 → 1.2.1)을 유발합니다.
범위(scope) 필드는 언제 사용해야 하나요?
변경 사항이 영향을 미치는 코드베이스의 컴포넌트, 모듈, 또는 영역을 식별하는 데 사용하세요. 일반적인 값: auth, api, ui, database, config, docs, deps. 범위는 선택 사항이지만 모노레포나 여러 팀이 같은 저장소에서 작업하는 대규모 프로젝트에서 매우 유용합니다. git log --oneline으로 영역별 커밋 히스토리를 필터링할 수 있습니다.
Breaking Change는 어떤 경우에 해당하나요?
Breaking Change는 API, CLI, 또는 라이브러리 사용자가 기존 코드를 수정해야 하는 모든 변경 사항입니다. 예: 공개 함수 제거, 함수 시그니처 변경, API 엔드포인트 이름 변경, 설정 파일 구조 변경. Breaking Change 체크박스를 체크하고 변경 사항과 마이그레이션 방법을 설명하세요. 이는 메이저 버전 업(예: 1.2.3 → 2.0.0)을 유발합니다.
설명에 72자 제한이 있는 이유는?
72자 제한은 git log와 GitHub 풀 리퀘스트 규약에서 비롯됩니다. git log --oneline은 대부분의 터미널 너비에서 약 72자보다 긴 제목을 잘라냅니다. GitHub도 PR 커밋 목록과 blame 뷰에서 긴 커밋 제목을 줄바꿈하거나 잘라냅니다. 제목을 짧게 유지하면 간결한 요약을 작성하게 되고, 세부 사항은 커밋 본문으로 이동합니다.
커밋 본문에는 무엇을 써야 하나요?
커밋 본문에는 무엇이 변경되었는지가 아니라 변경의 동기를 설명해야 합니다. "왜 필요했는가?"와 "새로운 방식이 기존 방식과 어떻게 다른가?"를 작성하세요 — diff가 이미 무엇이 변경되었는지 보여줍니다. 버그 수정의 경우 근본 원인을, 리팩토링의 경우 설계 근거를 설명하세요. 좋은 커밋 본문은 변경 사항이 병합된 몇 달 후에 회귀를 디버깅할 때 매우 가치 있습니다.
터미널에서 이 커밋 메시지를 어떻게 사용하나요?
미리보기에서 생성된 메시지를 복사하세요. 터미널에서 git add로 변경 사항을 스테이징한 후, git commit을 실행하면 기본 에디터가 열립니다. 거기에 메시지를 붙여넣으세요. 단일 줄 커밋의 경우 git commit -m "feat(scope): description"을 사용하고, 여러 줄 메시지의 경우 git commit -m "제목" -m "본문 단락"을 사용할 수 있습니다.
Conventional Commits로 changelog를 자동 생성하는 도구는?
Conventional Commits를 파싱하여 릴리스를 자동화하는 도구가 여러 가지 있습니다: standard-version(npm 패키지), semantic-release(완전한 CI/CD 자동화), release-please(GitHub Actions), changesets(모노레포 중심). 이 도구들은 커밋 히스토리를 읽어 다음 시맨틱 버전을 결정하고 CHANGELOG.md를 생성하여 수동으로 changelog를 관리할 필요를 없애줍니다.