깃 커밋 메세지 규칙

커밋 메세지는 집단별로 다양한 방식으로 쓰이고 있는데요.

커밋 메세지을 작성하는 이유와 구성 방법에 대해 설명해보겠습니다.

커밋 메세지 규칙을 정의하는 이유

 

일관성 유지
일관된 형식을 사용하면 커밋 메시지를 읽는 사람이 각 커밋의 목적을 쉽게 이해할 수 있습니다. 예를 들어, feat은 새로운 기능 추가, fix는 버그 수정 등으로 구분하면 커밋 내용을 빠르게 파악할 수 있습니다.

 

협업 효율성
여러 사람이 함께 작업하는 프로젝트에서는 커밋 메시지가 중요한 역할을 합니다. 메시지가 일관되게 작성되면 다른 개발자들이 작업 내역을 이해하는 데 드는 시간이 줄어들고, 수정 사항을 추적하는 데도 유리합니다.

 

버전 관리 용이성
버전 관리에서 커밋 메시지는 변경 이력을 추적하는 데 중요한 요소입니다. 예를 들어, 기능을 추가할 때는 feat으로 시작하고, 버그를 수정할 때는 fix로 시작하는 것이 분명히 구분되어 있으면 이후 버전에서 해당 변경 사항을 찾는 것이 쉬워집니다.

 

자동화 도구 활용
CI/CD 파이프라인, 릴리스 노트 생성, 자동화된 버전 관리 도구 등에서는 커밋 메시지를 기반으로 작업을 수행합니다. 예를 들어, chore 커밋은 배포나 버전 변경에 영향을 미치지 않기 때문에 릴리스 노트에서 제외될 수 있습니다.

 

문서화 및 코드 문서화
커밋 메시지는 코드 변경의 문서 역할을 합니다. 커밋 메시지에 어떤 기능이 추가되었거나 수정되었는지를 기록하는 것은 코드 변경 사항을 설명하는 데 유용합니다. 시간이 지나면 코드에서 무엇을 변경했는지 이해하는 데 도움이 됩니다.

 

 

 

커밋 메세지 작성 하는 방법

 

1. 커밋 타입 정의

커밋 타입은 어떤 변경을 했는지 표시 하는 것 입니다.

아래와 같은 예시가 있는데 아래에 있는 커밋 타입을 모두 사용하지 않아도 됩니다.

팀원들과 논의 후에 필요한 타입만 간소화 하여 사용하여도 됩니다.

예를 들면 fix, refactor, style 등은 update로 통일하여 사용할수 있습니다.

다만 이렇게 되면 한눈에 정확한 내용을 알기 어렵기 때문에 커밋 메세지에 어떤 변경을 했는지 설명해두는 편이 좋습니다.

 

• add: 새로운 기능을 추가한 경우 
  예시: add(auth): add password reset functionality
• fix: 버그를 수정한 경우
  예시: fix(api): resolve null pointer exception in user service
• docs: 문서 관련 수정
  예시: docs(readme): update API documentation for new endpoints
• style: 코드 스타일 변경 (기능에 영향을 미치지 않음)
  예시: style(header): fix indentation and add spacing
• refactor: 코드 구조 변경 (기능에 변화 없음)
  예시: refactor(userService): optimize user validation logic
• test: 테스트 코드 추가 및 수정
  예시: test(api): add unit tests for user service
• chore: 기타 관리 작업 (빌드 도구나 패키지 업데이트 등)
  예시: chore(build): update webpack configuration
• hotfix: 긴급한 버그 수정 (배포 후 즉시 수정이 필요한 문제 해결)
  예시: hotfix(payment): fix payment gateway issue after deployment
• build: 빌드 관련 작업 (빌드 설정 변경 등)
  예시: build: upgrade to Node.js v14.17.0
• ci: 지속적 통합(CI) 및 지속적 배포(CD) 관련 설정 변경
  예시: ci: update GitHub Actions workflow for deployment
• perf: 성능 개선 작업
  예시: perf(database): optimize query to reduce load time
• revert: 이전 커밋을 되돌리는 작업
  예시: revert(userService): revert changes to user validation logic

2. 범위 정의

auth, ui, api와 같이 변경된 부분이나 모듈의 범위를 적어야지 특정 기능의 ui가 바뀐것인지, api가 바뀐것인지 등을 식별하기 쉽습니다.

 

예를들어 fix: resolve null pointer exception 이런식으로 올라온 커밋이 있다면 어느 모듈에서 난 문제인지 파악하기 쉽지 않습니다.

fix(auth): resolve null pointer exception during login 이런 식으로 작성 하면 auth 모듈에서 난 문제라는 것을 쉽게 파악할 수 있습니다.

 

3. 본문 정의

메세지 본문에 넣을 내용에는 간결하고 명확한 내용으로 설명해야 하기 때문에 아래와 같은 규칙을 정할수 있습니다.

- 50글자 내로 작성

- 소문자로만 작성

- 명확한 내용으로 작성

- 최대한 짧게 작성

- 제목과 본문은 빈 행으로 구분

- 명령문으로 작성

- 영어로 작성

 

4. 형태 정의

위에서 정한 내용들을 어떻게 배치해서 쓸건지 정해야 하는데 아래와 같은 다양한 방법이 있습니다.

가독성이 좋은 방식으로 협의 하셔서 사용하시면 됩니다.

 

타입(범위) - 본문

feat(auth) - Add support for multi-factor authentication

 

타입(범위): 본문

feat(auth): Add support for multi-factor authentication

 

타입: 본문 (범위는 생략)

feat: Add support for multi-factor authentication

 

[타입] 범위 - 본문

[feat] auth - Add support for multi-factor authentication

 

타입 범위 | 본문

feat auth | Add support for multi-factor authentication

 

타입(범위) - 본문 (부가 설명 줄바꿈 포함)

feat(auth): Add multi

-factor authentication

- Supports email and SMS-based authentication - Includes backup codes for account recovery

 

5. 기타

커밋 메세지에 추가 될수 있는 요소들은 다양한데요 1.2.1 이런 작업 번호를 추가 할수도 있습니다.

각 프로젝트에서 식별해야 하는 중요한 포인트가 있다면 해당 내용을 간결하고, 명확한 규칙을 정하여 추가하시면 됩니다.