git 커밋컨벤션 설정법

글을 작성하는 이유

커밋을 하면서 협업을 하게 된다면 커밋을 제대로 해야되다는 필요성을 느끼게 되어서 이리저리 알아보았다.

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

이블로그를 참고해서 작성하였다.

 

커밋메시지의 구조

구조는 크게 type, subject, body, footer로 구분하여 작성한다.

 

type : 어떤 의도로 커밋했는지 작성한다.

subject : 코드 변경 사항에 대한 짧은 요약을 작성한다.

body : 어떻게 했는지가 아니라, 무엇을 왜 했는지를 작성한다.

footer : issue tracker ID를 명시하고 싶은 경우 작성한다(선택)

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

 

type 작성법 

[feat]	새로운 기능을 추가할 경우
[fix]	버그를 고친 경우
[design]	CSS 등 사용자 UI 디자인 변경
[style]	코드 포맷변경, 세미콜론 누락, 코드수정이 없는 경우.
[refactor]	프로덕션 코드 리펙토링할 경우
[comment]	필요한 주석 추가 및 변경
[docs]	문서를 수정한 경우
[test]	테스트 코드 작업을할 경우
[chore]	빌드 테스트 업데이트, 패키지 매니저를 설정하는 경우
[rename]	파일 혹은 폴더명을 수정하거나 옮기는 작업만 하는 경우
[remove]	삭제하는 작업만 수행한 경우
[init]	브랜치 초기화 및 초기셋팅 관련된 설정일 경우

type을 작성한뒤 뒤에 ":"를 붙인다.

 

subject작성법

코드 변경 사항에 대한 짧은 요약을 나타낸다.

 

다음의 규칙은 가진다.

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

 

한글로 작성시 규칙 

1. "고침", "추가", "변경"의 명령어로 시작한다.

 

영어로 작성시 규칙

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

 

예시)
[feat]: 추가 get data api 함수

 

body 작성법

 

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

 

footer 작성법

선택사항이다.(나는 아주 큰 규모의 프로젝트에서만 사용할 듯)

 

다음의 규칙이 있다.

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

 

예시

[feat]: 추가 get data api 함수

로그인 API 개발

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