커밋 메시지 형식

Source: Dev.to

커밋 메시지 형식

각 커밋 메시지는 헤더, 본문, 그리고 푸터 로 구성됩니다. 헤더는 type, 선택적인 scope, 그리고 subject 를 포함하는 특별한 형식을 갖습니다:

<type>(<scope>): <subject>

헤더는 필수이며, scope는 선택 사항입니다.

예시 – fix: remove unused dependency lodash.camelcase

커밋 메시지의 모든 줄은 100자를 초과하지 않아야 합니다. 이는 GitHub 및 다양한 Git 도구에서 메시지를 읽기 쉽게 해 줍니다.

Type

다음 중 하나여야 합니다:

• feat: 새로운 기능.
• fix: 버그 수정.
• docs: 문서 전용 변경.
• style: 코드 의미에 영향을 주지 않는 변경(공백, 포맷팅, 세미콜론 누락 등).
• refactor: 버그를 수정하거나 기능을 추가하지 않는 코드 변경.
• perf: 성능을 개선하는 코드 변경.
• test: 누락된 테스트 추가.
• chore: 빌드 프로세스 또는 보조 도구와 라이브러리 변경(예: 문서 생성).
• ci: CI 설정 파일 및 스크립트 변경.
• build: 빌드 시스템이나 외부 의존성에 영향을 주는 변경(예: gulp, broccoli, npm).
• revert: 이전 커밋을 되돌림.
• wip: 진행 중인 작업; 나중에 커밋이 제거될 수 있음.

Scope

scope는 선택 사항이며, 변경이 영향을 미치는 코드베이스 영역을 지정할 수 있습니다. 예: nsis, mac, linux 등.

Subject

subject는 변경에 대한 간결한 설명을 포함합니다:

• 명령형 현재 시제를 사용합니다(예: “change”, “changed”가 아니라).
• 첫 글자를 대문자로 쓰지 않습니다.
• 마침표로 끝내지 않습니다.

Body

• 명령형 현재 시제로 작성합니다.
• 변경 동기와 이전 동작과의 차이를 설명합니다.

Footer

푸터는 다음 용도로 사용됩니다:

• Breaking changes – BREAKING CHANGE: 로 시작하고 뒤에 공백 또는 두 개의 줄바꿈을 둡니다.
• 이 커밋이 닫는 GitHub 이슈를 명시(예: Closes #123).

베스트 프랙티스

• 의미 있는 커밋 메시지를 작성 – 무엇이 바뀌었고 왜 바뀌었는지를 명확히 전달합니다.
• 작은 커밋을 유지 – 각 커밋은 하나의 논리적 변경을 나타내야 합니다.
• 브랜치를 사용 – 기능이나 버그 수정마다 새로운 브랜치를 만듭니다.
• 머지하기 전에 커밋을 스쿼시 – 히스토리를 깔끔하게 유지합니다.
• 커밋 전에 리뷰 – 코드가 프로젝트 표준을 따르고 테스트를 통과했는지 확인합니다.
• 테스트 자동화 – 각 커밋마다 자동 테스트를 실행해 회귀를 조기에 발견합니다.
• 일관된 스타일을 따름 – 프로젝트 스타일 가이드를 준수해 일관성을 유지합니다.

참고 문헌

• FreeCodeCamp. (2022, March 2). How to write better Git commit messages. https://www.freecodecamp.org/news/how-to-write-better-git-commit-messages/
• Beams, C. How to write a Git commit message. https://cbea.ms/git-commit/
• 2my. (2021, October 30). Git conventional commits. https://blog.2my.xyz/2021/10/30/git-conventional-commits/