<Git> Commit Message 중요성 및 규칙

 

일관성이 없는 메세지 내용은 각 커밋의 위치에서 어떤 작업을 했는지 명확하게 알아 볼 수 없다.

또한 시각적 통일성을 떨어뜨려 커밋 히스토리를 파악하는데 어려움을 줄 수 있기 때문에 협업 전 커밋 규칙을 정하는 것이 중요하다. 따라서 오늘은 커밋 메세지를 일관성있는 규칙으로 작성하는 방법을 정리하려 한다.

 

1. Commit Message 구조

---

type(타입) : title(제목)

body(본문, 생략 가능)

Resolves : #issueNo, ...(해결한 이슈 , 생략 가능)

See also : #issueNo, ...(참고 이슈, 생략 가능)

 

 

 

 

 

2. 기본규칙

---

• 제목과 본문을 빈 행으로 구분
• 제목은 영문 기준 50글자 이하
• 첫 글자는 대문자로 작성
• 제목 끝에 마침표X
• 제목은 명령문으로 사용, 과거형X
• 본문의 각 행은 영문 기준 72글자 이하
• 어떻게 보다는 무엇과 왜

 

 

 

 

3. Type

---

Type 키워드	사용 시점
feat	새로운 기능 추가
fix	버그 수정
docs	문서 수정
style	코드 스타일 변경 (코드 포매팅, 세미콜론 누락 등) 기능 수정이 없는 경우
design	사용자 UI 디자인 변경 (CSS 등)
test	테스트 코드, 리팩토링 테스트 코드 추가
refactor	코드 리팩토링 (ex. 변수명 수정 등의 작업 포함)
build	빌드 파일 수정
ci	CI 설정 파일 수정
perf	성능 개선
chore	빌드 업무 수정, 패키지 매니저 수정 (gitignore 수정 등), production code와 무관한 부분
rename	파일 혹은 폴더명을 수정만 한 경우
remove	파일을 삭제만 한 경우

 

대부분 가장 많이 사용하는 것은 feat와 fix이다.

style, design처럼 로직적인 변화가 없을 경우는 커밋 메세지에 명시 해 주는 것 만으로도 추후 오류를 찾을 때 도움이 된다.

 

 

 

 

4. 커밋 메세지 예제

---

Feat: 관심지역 알림 ON/OFF 기능 추가(#123)

시군구의 알림을 각각 ON/OFF 할 수 있도록 기능을 추가함
 - opnion0055: 구분 코드

해결: close #123

 

 

---

협업 시 서로의 작업 내용을 한 눈에 파악할 수 없기 때문에 작성한 커밋에 대한 내용을 잘 적는 것이 중요하다. 팀에서 위와 같은 컨벤션으로 일 할 수 있다면 히스토리를 파악하고 코드 리뷰도 짧은 시간 내에 해결할 수 있을 것 같다.