Commit Convention (유다시티 커밋 메세지 스타일 가이드)

커밋 컨벤션

커밋(Commit)은 프로젝트의 변경사항을 메시지와 함께 저장하는 것을 의미한다. 커밋을 하게 되면 메시지가 남는데 이를 통해서 자기가 작업했던 시점으로 돌아가거나, 수정된 내역을 찾아서 프로젝트 진행에 있는 부분에 있어서의 등등 여러 이점을 받을 수 있다. 혼자 작업한다면, 자신이 알아보기 쉽게만 커밋 메세지를 작성해도 무방하나, 협업 같은 활동을 하게 된다면 읽는 사람이 이해하기 쉽도록 메시지를 작성하여야 한다. 해당 문제를 해결하기 위해서 다른 사람들이 자주 사용하는 커밋 스타일을 정하고 이를 활용한다면 많은 효과를 가져다줄 것이라고 생각한다. 

 

따라서 사람들이 자주 사용하고 있는, Udacity의 깃 커밋 스타일 가이드를 바탕으로 커밋 컨벤션을 정리하려고 한다. 

 

 

 

커밋 메세지의 구조와 타입 

먼저 커밋 메세지는 크게 제목, 본문, 꼬리말 3가지 파트로 분류하며, 각 파트는 빈 줄을 두어서 구분한다. 

type(옵션): [#issueNumber - ]Subject  // -> 제목
(한 줄을 띄워 분리합니다.)
body(옵션) //  -> 본문 
(한 줄을 띄워 분리합니다.)
footer(옵션) // -> 꼬리말

 

• type : 어떤 의도로 커밋했는지를 type에 명시한다.
• subject : 최대 50글자가 넘지 않도록 하고 마침표는 찍지 않는다. 영문으로 표기하는 경우 동사(원형)를 가장 앞에 두고 첫 글자는 대문자로 표기한다.
• body : 긴 설명이 필요한 경우에 작성한다. 어떻게 했는지가 아니라, 무엇을 왜 했는지를 작성합니다. 최대 75자를 넘기지 않도록 한다.
• footer : issue tracker ID를 명시하고 싶은 경우에 작성한다.

제목을 작성 할때는 "태그: 제목"의 형태로 작성하며, : 뒤에만 공백이 있다는 점을 유의하여야 한다. 

 

 

 

각 태그에 따른 종류

• Feat : 새로운 기능 추가
• Fix : 버그 수정
• Design : CSS 등 사용자 UI 디자인 변경
• !BREAKING CHANGE : 커다란 API 변경의 경우 (ex API의 arguments, return 값의 변경, DB 테이블 변경, 급하게 치명적인 버그를 고쳐야 하는 경우)
• Style : 코드 formatting, 세미콜론(;) 누락, 코드 변경이 없는 경우
• Refactor : 코드 리팩터링
• Comment : 필요한 주석 추가 및 변경
• Test : 테스트 코드, 리팩터링 테스트 코드 추가
• Chore : 빌드 업무 수정, 패키지 매니저 수정, 자잘한 수정이나 빌드 업데이트
• Docs : 문서 수정
• Rename : 파일 혹은 폴더명을 수정하거나 옮기는 작업만인 경우
• Remove : 파일을 삭제하는 작업만 수행한 경우
• Perf : 성능 개선

 

추가적인 문맥 정보를 제공하기 위해서 괄호 안에 적을 수도 있다.

"Feat(navigation): "
"Fix(database): "

 

 

 

각 구조에 대한 규칙

제목은 코드 변경 사항에 대한 짧은 요약을 나타내며, 다음의 규칙을 지킨다. 

1. 제목의 처음은 동사 원형으로 시작한다.
2. 총 글자 수는 50자 이내로 작성한다.
3. 마지막에 특수문자는 삽입하지 않는다. 예) 마침표(.), 느낌표(!), 물음표(?)
4. 제목은 개조식 구문으로 작성한다.

 

만약 영어로 작성하는 경우 다음의 규칙을 따른다. 

1. 첫 글자는 대문자로 작성한다.
2. "Fix", "Add", "Change"의 명령어로 시작한다.

 

한글로 제목을 작성하는 경우 다음의 규칙을 따른다.

1. "고침", "추가", "변경"의 명령어로 시작한다.
예시) Feat: "추가 get data api 함수"

 

 

본문을 작성할 때에는 다음의 규칙을 지킨다. 

1. 본문은 한 줄 당 72자 내로 작성합니다.
2. 본문 내용은 양에 구애받지 않고 최대한 상세히 작성합니다.
3. 본문 내용은 어떻게 변경했는지 보다 무엇을 변경했는지 또는 왜 변경했는지를 설명합니다.

 

 

꼬리말은 다음과 같은 규칙을 지킨다.

1. 꼬리말은 optional이고 이슈 트래커 ID를 작성합니다.
2. 꼬리말은 "유형: #이슈 번호" 형식으로 사용합니다.
3. 여러 개의 이슈 번호를 적을 때는 쉼표로 구분합니다.
4. 이슈 트래커 유형은 다음 중 하나를 사용합니다.
    - Fixes: 이슈 수정 중 (아직 해결되지 않은 경우)
    - Resolves: 이슈를 해결했을 때 사용
    - Ref: 참고할 이슈가 있을 때 사용
    - Related to: 해당 커밋에 관련된 이슈번호 (아직 해결되지 않은 경우)
ex) Fixes: #45 Related to: #34, #23

 

해당 내용을 지킨 상태로 로그인 API을 개발한 내용을 커밋할 때, 커밋 메시지를 작성한다면 다음과 같이 나타 낼 수 있다. 

Feat: "추가 로그인 함수"

로그인 API 개발

Resolves: #123
Ref: #456
Related to: #48, #45

 

 

Gitmoji을 활용한 커밋 

커밋 메세지를 읽기 쉽게 하기 위해서 이모지 (🥹😒)를 이용한 커밋을 활용하기도 한다. 해당 부분의 자세한 내용은 아래에 있는 블로그를 참고하자.

 

깃모지 사용법 정리 :  https://inpa.tistory.com/entry/GIT-%E2%9A%A1%EF%B8%8F-Gitmoji-%EC%82%AC%EC%9A%A9%EB%B2%95-Gitmoji-cli

⚡️ Gitmoji 사용법 정리 (+ 깃모지 툴 소개)

 

 

---

참조 : 

 

https://velog.io/@shin6403/Git-git-%EC%BB%A4%EB%B0%8B-%EC%BB%A8%EB%B2%A4%EC%85%98-%EC%84%A4%EC%A0%95%ED%95%98%EA%B8%B0

Git | git 커밋 컨벤션 설정하기

https://overcome-the-limits.tistory.com/entry/%ED%98%91%EC%97%85-%ED%98%91%EC%97%85%EC%9D%84-%EC%9C%84%ED%95%9C-%EA%B8%B0%EB%B3%B8%EC%A0%81%EC%9D%B8-git-%EC%BB%A4%EB%B0%8B%EC%BB%A8%EB%B2%A4%EC%85%98-%EC%84%A4%EC%A0%95%ED%95%98%EA%B8%B0

[협업] 협업을 위한 git 커밋컨벤션 설정하기