[Git] Commit Message Convention (feat: 로그인 기능 추가)

2025.06.14 - [Git(깃)] - [Git] Semantic Version 관리 (v1.0.0-rc.1)

[Git] Semantic Version 관리 (v1.0.0-rc.1)

버전 관리에 Sematic Version 을 적용한 것처럼 커밋에서도 비슷한 것이 있지 않을까?

깃에서 가장 많이 사용하는 명령어 중 하나가 commit 일 것이니, 이런 규칙이 있다면 일관성을 유지하면서 협업하기 좋을 것이다.

 

팀 프로젝트나 오픈소스를 보다 보면 이런 커밋 메시지를 자주 본다.

• feat: 로그인 기능 추가
• fix: 로그인 버튼 버그 수정

실제로 이러한 커밋 메시지들은 특정한 규칙에 의해 씌여져 있다.

 

Git Commit Message Convention

커밋 메시지를 일정한 형식으로 작성하기 위한 규칙이다.

커밋 메시지는 아래와 같이 구성된다.

<type>[optional scope]: <description>
(빈줄)
[optional body]
(빈줄)
[optional footer(s)]

• type : 커밋의 종류 작성
• subject: 변경 사항 작성
• body: (type:subject) 대한 설명이 추가로 필요할 때 작성
• footer: 이슈와 연결하기 위해 이슈 번호 기록. 그외에도 CI 등에 활용할 수 있다. ex. 자동 릴리즈 노트 작성
  (나는 Github 에서 Pull Request 할 때, Close #1234 같이 적어서 일감을 닫게 한다.)

예시.
feat: 로그인 기능 추가

- 사용자 로그인 기능 구현
- 아이디와 비밀번호 입력 및 인증 처리

Closed: #1234

 

타입의 종류

주로 사용하는 type 의 예시이다.

• feat: 새로운 기능 추가
• fix: 버그 수정
• docs: 문서 관련 수정
• style: 코드 포맷 변경(공백, 세미콜론 등)
• refactor: 리팩토링(기능 변화 없음)
• test: 테스트 코드 추가/수정
• chore: 빌드 설정, 패키지 업데이트 등 기타 잡일

커밋 메시지 작성시 유의사항

• 무엇을 했는지 설명
  • 어디 코드를 수정함(X) -> 로그인 시 비밀번호 검증 오류 수정(O)
• 변경 사항을 파악할 수 있도록 작성
  • fix: 로그인 오류 수정(X) -> fix: 비밀번호 5회 실패 시 무한 대기 현상 수정(O)
• 제목은 명령형으로 작성
  • add, fix, ...
  • 과거형은 쓰지 않는다. added(X)

 

 

위의 내용은 가이드라인일뿐이다.

규칙이 있다면 그 규칙을 기반으로 또 다른 것을 하기 쉬워진다.

예를 들어, 커밋메시지를 통해 CI 에서 Version 을 자동으로 관리할 수도 있다.

 

하지만 아래의 예시처럼 다양한 방식으로 커밋메시지를 작성하기 때문에 너무 강박감을 가질 필요는 없다.

결국은 상대방과 쉽게 소통하고 협업하기 위함임을 잊지말자.

Commit 예시