[Git] 커밋 메시지 컨벤션 (Commit message Convention)

 

 

 

 

 

커밋 컨벤션이 필요한 이유

• 커밋 컨벤션: 공통적인 커밋 메시지 규약
• 커밋 메시지가 늘어날 수록, 형식을 지키지 않은 커밋 메시지들은 한 눈에 뭐가 뭔지 알기 어려워진다.
• 가독성과 이해력이 좋아진다. 일관된 커밋 메시지 형식은 협업하는 동료들이 커밋을 쉽게 이해하고 코드 변경 내용을 파악할 수 있도록 도우며, 커밋 메시지가 명확하고 간결하면 다른 개발자가 코드 기록을 쉽게 추적할 수 있다.
• 변경점을 찾기가 쉬워진다. 유지 보수시에 용이해진다.

 

---

 

커밋 메시지 구조

Feat: Add login API        // 타입: 제목

로그인 API 개발               // 본문 (선택)

Resolves: #123              // 꼬리말 (issue tracker ID 를 명시하고 싶은 경우에 작성 => 이슈 123을 해결했으며,
Ref: #456                                 이슈 456 를 참고해야하며,
Related to: #48, #45         현재 커밋에서 아직 이슈 48 과 45 가 해결되지 않았다.

 

 

 

1. 타입(Commit Type)

 

• 태그(tag): 제목(subject) 형태 
• 태그는 영어로 쓰되, 첫 문자는 대문자, ":" 뒤에 공백

 

태그

• Feat : 새로운 기능을 추가하는 경우
• Fix : 버그를 고친경우
• Docs : 문서를 수정한 경우
• Style : 코드 포맷 변경, 세미콜론 누락, 코드 수정이 없는경우
• Refactor : 코드 리펙토링
• Test : 테스트 코드. 리펙토링 테스트 코드를 추가했을 때
• Chore : 빌드 업무 수정, 패키지 매니저 수정
• Design : CSS 등 사용자가 UI 디자인을 변경했을 때
• Rename : 파일명(or 폴더명) 을 수정한 경우
• Remove : 코드(파일) 의 삭제가 있을 때. (Clean, Eliminate 사용하기도 함)
• Add : 코드나 테스트, 예제, 문서등의 추가 생성이 있는경우
• Improve : 향상이 있는 경우 (호환성, 검증 기능, 접근성 등)
• Implement : 코드가 추가된 정도보다 더 주목할만한 구현체를 완성시켰을 때
• Move : 코드의 이동이 있는경우
• Updated : 계정이나 버전 업데이트가 있는 경우 (주로 코드보다는 문서나, 리소스, 라이브러리등에 사용)
• Comment : 필요한 주석 추가 및 변경

 

제목

• 코드의 변경 사항에 대해 짧은 요약
• 영어로 제목을 작성하는 경우
  - 제목은 50자를 넘기지 않고, 대문자로 작성하며 마침표를 붙이지 않는다.
  - 제목은 과거형을 사용하지 않고, 명령조로 시작 (Fixed bug가 아닌 Fix bug)
• 한글로 제목을 작성하는 경우
  - "고침", "추가", "변경" 등의 명령조 로 시작 (예: 추가 get clone 함수)

 

 

 

2. 본문(Body)

• 본문 작성은 선택사항
• 부연설명이 필요하거나 커밋의 이유를 설명할 경우 작성
• 무엇을 변경했는지 혹은 왜 변경했는지
• 제목과 구분되기 위해 공백 한 줄을 띄워서 작성

 

 

 

3. footer (꼬리말)

• footer 작성은 선택사항
• issue tracker id 를 작성할 때 사용
• 형식: 유형: #이슈 번호
• issue tracker 유형
  - Fixes : 이슈 수정중 (아직 해결되지 않은 경우)
  - Resolves : 이슈를 해결했을 때 사용
  - Ref : 참고할 이슈가 있을 때 사용
  - Related to : 해당 커밋에 관련된 이슈번호 (아직 해결되지 않은 경우)
  - ex) Fixes: #45 Related to: #34, #23
  
  

 

 

(참고 사이트1)