Git 커밋 메시지 템플릿

터미널과 에디터에서 확장되는 재사용 가능한 Conventional Commits 형식의 PR 준비 메시지 템플릿.

템플릿 카테고리 개요

일관된 커밋 메시지는 저장소의 기록을 읽기 쉽게 하고, 자동 changelog를 가능하게 하며, 코드 리뷰를 빠르게 합니다 — 하지만 잘 구조화된 Conventional Commit을 매번 손으로 입력하는 것은 충분히 번거로워서 대부분의 개발자가 한 줄 요약으로 돌아갑니다. 텍스트 확장기는 짧은 트리거를 타입, scope, 요약, 본문, 푸터가 이미 배치된 완전한 커밋 골격으로 바꾸어 이를 해결하므로, 형식을 기억하는 대신 세부 사항을 채웁니다. Lightning Assist는 시스템 전역에서 작동하므로 — 대부분의 커밋이 실제로 일어나는 터미널과 VS Code의 커밋 상자를 포함 — 명령줄, IDE, Git GUI 어디에서 커밋하든 동일한 템플릿이 작동합니다. Push-to-Talk 음성은 디버그 중 손이 키보드에서 떨어져 있을 때 더 긴 본문 단락을 받아쓰게 할 수도 있습니다.

이 템플릿을 사용해야 하는 경우

모든 커밋에 커밋 메시지 템플릿을 사용하되, 나중에 중요해지는 커밋에서 가장 효과를 발휘합니다. 다시 볼 버그 수정, 다른 팀에 영향을 주는 breaking changes, 기록에서 릴리스나 changelog를 자동 생성하는 저장소의 모든 커밋입니다. 프로젝트가 Conventional Commits, semantic-release 또는 changelog 자동화를 사용한다면 일관된 골격은 단지 정돈이 아니라 — tooling을 작동하게 하는 바로 그것입니다. 개인 프로젝트에서도 일관된 형식으로 작성된 읽기 쉬운 git log는 회귀를 bisect하거나 6개월 전 변경이 왜 이루어졌는지 기억하려 할 때 실제 시간을 절약합니다.

이 카테고리의 예제 템플릿

  • Conventional Commit 골격: 타입, 선택적 scope, 요약, 본문, ticket 참조가 있는 푸터.
  • 버그 맥락이 있는 fix 커밋: 무엇이 깨졌는지, 수정, 그리고 그것이 닫는 issue.
  • Breaking-change 커밋: 변경 사항과 릴리스 tooling을 위해 명확히 표시된 BREAKING CHANGE 푸터.

실제 예제 템플릿

Conventional Commit 골격

자동 버전 관리와 changelog 도구를 구동하는 Conventional Commits 사양을 따르는, 모든 커밋을 위한 일상 템플릿입니다. 구조는 타입(feat, fix, chore, docs, refactor, test 등), 괄호 안의 선택적 scope, 약 50자 미만의 간결한 명령형 요약, 빈 줄, 그다음 이유를 설명하는 본문, 그리고 ticket 참조용 푸터입니다. 이를 ;cc 같은 짧은 트리거에 두어 메시지를 쓰기 전에 터미널에서 확장되도록 합니다. 매번 일관된 골격을 채우는 것이 git log를 몇 달 후에 진짜 유용하게 만들며, changelog를 자동 생성할 수 있는 릴리스 도구와 그렇지 못한 도구의 차이입니다.

[#type#]([#scope#]): [#summary#]

[#why this change was made#]

Refs: [#ticket#]

버그 맥락이 있는 fix 커밋

버그 수정 커밋은 미래의 당신이 가장 이해해야 하는 것이므로 "fix bug" 이상의 가치가 있습니다. 세 가지를 포착하세요. 무엇이 깨졌는지(관찰 가능한 증상), 수정이 무엇을 하는지, 그리고 트래커가 자동 업데이트되도록 그것이 어떤 issue를 닫는지. "Closes #" 푸터가 바로 커밋을 issue 트래커에 연결하고 대부분의 플랫폼에서 merge 시 ticket을 닫습니다. 이를 ;fix 같은 트리거에 두세요. 디버깅 세션 깊숙이 있으면서 근본 원인을 평이한 언어로 기록하고 싶을 때, Push-to-Talk 음성은 흐름을 깨지 않고 본문을 받아쓰게 하며, AI Enhance는 장황하게 받아쓴 설명을 깔끔한 단락으로 다듬습니다.

fix([#scope#]): [#what was broken#]

[#root cause and what the fix does#]

Closes #[#issue#]

Breaking-change 커밋

커밋이 API, 설정 형식 또는 다른 코드가 의존하는 계약을 변경할 때, 릴리스 tooling이 major 버전 상승을 트리거하고 changelog가 사용자에게 경고하도록 breaking change는 명시적으로 표시되어야 합니다. Conventional Commits 표준은 바로 이를 위해 BREAKING CHANGE: 푸터(또는 타입 뒤의 !)를 사용합니다. 무엇이 깨졌는지, 그리고 무엇보다 사용자가 마이그레이션하려면 무엇을 해야 하는지 명시하세요 — 마이그레이션 노트 없는 breaking change는 그저 지원 질문의 홍수가 됩니다. 이를 ;ccbreak 같은 의도적인 트리거에 두어 정말로 의도할 때만 사용하세요. breaking change를 잘못 라벨링하는 것은 라벨링하지 않는 것보다 나쁘기 때문입니다.

[#type#]([#scope#])!: [#summary#]

[#what changed#]

BREAKING CHANGE: [#what consumers must change to migrate#]

Refs: [#ticket#]

시작하는 방법

타입, scope, 요약, 본문, ticket 플레이스홀더가 있는 ;cc 같은 짧은 트리거로 일반 Conventional Commit 골격부터 시작하세요. fix 타입과 "Closes #" 푸터가 미리 채워진 ;fix 변형, 그리고 드물지만 중요한 breaking 커밋용으로 BREAKING CHANGE 푸터가 있는 ;ccbreak 변형을 추가합니다. 터미널이나 에디터의 커밋 상자에 트리거를 입력하면 입력하는 동안 인라인으로 확장됩니다 — 단축키 없이, 확장이 시스템 전역이므로 둘 다에서 동일하게 작동합니다. 골격이 자연스러워지면 PR 설명과 코드 리뷰 답장 템플릿을 추가해 전체 변경 제출 흐름을 일관되게 만드세요.

전문가 팁

  • 요약 줄을 ~50자 미만, 명령형으로 유지하세요("add", "added"가 아님) — 대부분의 git tooling과 리뷰어가 이 관례를 기대합니다.
  • fix 커밋에 "Closes #[issue]" 푸터를 사용해 변경의 merge가 트래커에서 연결된 ticket을 자동으로 닫도록 하세요.
  • breaking-change 템플릿은 진짜 계약 변경을 위해 남겨두고 항상 마이그레이션 단계를 포함하세요 — 그것이 없는 breaking 노트는 지원 부담만 만듭니다.
  • 디버그 중 손이 키보드에서 떨어져 있을 때 Push-to-Talk로 커밋 본문을 받아쓰고, 그다음 AI Enhance로 표현을 다듬으세요.

모든 앱에서 이 템플릿을 사용하세요

이러한 예제에서 재사용 가능한 스니펫을 만들고 빠른 액세스, 트리거 단축키 또는 AI 향상 기능을 사용하여 실행하세요.

무료 평가판 시작

관련 페이지 및 스니펫

귀하의 워크플로에 대한 관련 가이드, 템플릿 및 비교를 살펴보세요.