Git 커밋 컨벤션을 지키면서 Commit하기!

계산기 프로젝트를 개발 평가 기준에 "커밋 컨벤션을 지킨 커밋을 10회 이상 시행"이라는 항목이 있었다.
GUI 구현에 눈이 멀어 이 부분을 놓쳤다.
따라서, 다음 프로젝트 개발에 앞서 이 부분을 간단하게 정리하고 넘어가고자 한다.

---

Commit  메시지 구조

✅ type : 제목
✅ body : 본문
✅ footer : 꼬리말

Type 

Commit의 목적을 나타낸다.
(코드 생성, 수정 등의 변경 내용을 요약하는 단어다! 라고 이해했다.)

첫 문자가 소문자인 영어로 작성한다.

코드 작성 관련 태그

태그 이름	설명
Feat	새로운 기능을 추가했을 때
Style	세미콜론 추가, 공백 수정 등 코드 스타일을 변경했을 때
Refactor	코드를 리팩토링 했을 때
Design	CSS 등 사용자 UI 디자인을 변경했을 때
Comment	필요한 주석을 추가 및 변경했을 때
!BREAKING CHANGE	API를 크게 변경했을 때

 

문서 또는 파일 변경 관련 태그

태그 이름	설명
Docs	문서를 수정했을 때
Rename	파일, 폴더명을 수정하거나 옮겼을 때
Remove	파일을 삭제했을 때

 

버그, 테스트 관련 태그

태그 이름	설명
Fix	버그를 고쳤을 때
!HOTFIX	치명적인 버그를 빠르게 고쳐야할 때
Test	테스트 추가, 테스트 리팩토링
Chore	빌드 테스트 업데이트, 패키지 매니저를 설정할 때

 

Body

무엇을, 왜 변경했는지를 설명한다.
(어떻게 변경했는지보다 변경 원인이 더 중요하다)

Footer

필수로 입력해야 하는 것은 아니다.

유형 : #이슈 번호

이슈를 수정하는 과정에서 주로 사용하는 것 같다.

이슈 트래커	설명
Fixes	이슈를 수정 중이다.
Resolves	이슈를 해결했다.
Ref	참고할 이슈가 있다.
Related to	해당 커밋에 관련된 아직 해결되지 않은 이슈가 있다.

 

---

실제 사용 예시

📌 새로운 기능을 추가한 경우

git commit -m "feat(App): 리스트에 저장된 원소를 출력하는 메서드 추가"

괄호를 사용해 기능을 추가한 파일의 범위를 표기할 수도 있다.

 

📌 기존 코드를 정리하며 클래스를 분리한 경우

git commit -m "refactor(Calculator): 반복되는 연산 과정을 메서드로 분리"

---

느낀 점

커밋 컨벤션을 알아본 후 약간 반성의 시간을 가졌다.

이번에 계산기 프로젝트를 개발할 때, 코드를 리팩토링하는 과정에서 거슬리는 파일은 과감하게 지우고,
코드 스타일도 바꾸는 등 이것저것 왕창 건들면서 리팩토링 한 후 Modify라는 단어로 퉁치고
한 번에 커밋한 전적이 여러 번이기 때문이었다.

커밋 컨벤션을 사용하는 방법을 보면서
리팩토링할 때는 리팩토링만 한 후 커밋하고, 코드 스타일을 바꿀 때는 코드 스타일만 바꾼 후
커밋을 해야겠다는 걸 느꼈다.

협업이기 때문에 이런 부분을 더 세심하게 신경 쓰는 것 같다.

새로운 프로젝트부터는 커밋 컨벤션을 지켜가며 개발해보고자 한다.