혼자서 github로서 저장의 목적으로 사용할 때에는 굳이 신경쓰지 않았던 부분이다. 하지만, 회사에서 한번 사용을 해보았을 때 컨벤션이 지정되어있지 않다면 많은 불편함이 수반된다는 것을 몸소 느낄 수 있었다... 만약, 그냥 어떤 코드를 수정했다 라고만 저장을 해둔다면, 추후에 다시 확인하거나 누군가가 질문하여 답을 해야한다면 오류때문에 바꿨는지 아니면 리펙토링을 진행한 것인지, 아니면 빌드가 안되서 바꾼것인지에 대해 명확성이 드러나지 않던 것이 혼자 git에 저장하던 방식대로 커밋메시지를 작성하였다면 제대로 답을 하지 못했을거라 생각이 들었다.
커밋 메시지의 컨벤션을 잘 활용한다면, 굳이 코드를 들여다 보지 않더라도 어느정도 파악이 가능하고 개개인이 자신들만의 규칙으로 작성한 것보다 통일되어있다면 시간절약을 할 수 있다는 생각에 이번 프로젝트에도 적용시키기로 생각을 해보았다..
Commit 유형
Commit의 헤드라인 부분에 적용
헤드라인에 먼저 표시한다면, 버그 수정의 경우에만 확인할때 본문 메시지를 확인하지 않고서도 빠르게 찾을 수 있는 효과가 있다.
또한, 목적성을 확실히 보일 수 있어서 본문 메시지를 작성하기에도 수월해진다
Commit 유형
Commit 유형 설명
FEAT
새로운 기능의 추가
FIX
버그 수정
DOCS
문서 수정
STYLE
코드 포맷팅, 세미콜론 누락, 코드자체 변경 없는경우 (스타일 변경)
REFACTOR
코드 리펙토링
TEST
테스트 코드 추가
CHORE
빌드 업무 수정, 패키지 매니저 수정 (ex .gitignore 수정)
Commit Message 작성 방법
[제목] 1. 제목과 본문을 빈행으로 분리 2. 제목행은 간결하게 표현 3. 제목행의 첫글자는 대문자로 시작 4. 제목행 끝에는 마침표를 넣지 않는다
[본문] 1. 본문은 72자마다 끊어서 줄을 바꿔준다 2. 본문을 사용하여 변경한 내용과 이유 설명 3. 자신의 코드가 직관적으로 파악할 수 있다고 생각하지 말고 작성하기
Commit 예시
git commit -m " FEAT : 게시판 기능 추가 // [제목]
//[본문] 1. 게시판 삭제 기능 추가 2. 게시판 생성 기능 추가 3. 게시판 수정 기능 추가 4. 게시판 조회 기능 추가
"
메시지 내용
"[Commit 유형] : [제목] { [본문] } "
Commit 메시지의 습관화..
현재 날짜) 25.1.4 다시 회고를 하며 포스팅을 수정중에 있다. 처음 작성할때는 부족했던 것도 있고 수정해야할 부분들도 있으니 다시 보며 오류를 잡고 첨삭 작업을 진행중에 있는데,
commit message의 경우에는 정말 잘 했다는 생각이 들었다. 물론, 팀프로젝트를 진행할때 각자의 습관들이 있거나 빠른 결과물을 위해서 가끔씩 지켜지지 않은 경우는 있었으나 쓴이의 경우 의식하며 지키려고 노력했다. 초반에는 잘 느끼지 못하다가 점차 커밋 로그가 쌓일때마다 통일감이 느껴지고 나중에 로그기록을 보면서 찾기에 수월함을 확실히 느낄 수 있었고, 그 때의 기억이 단순히 본문만 적던 커밋메시지 보다 확실히 더 빠르게 떠올랐었다.
앞으로도 계속해서 커밋 컨벤션의 경우 혼자서 프로젝트를 진행할때라도 계속해서 지켜가며 작성할 예정이다..!
