규칙을 정해 커밋 메세지를 작성하면 어떤 기능이 추가되었는지 어떤 버그가 수정되었는지 어떤 리팩토링을 했는지 알 수 있다.
많은 곳에서 사용되고 있는 규칙적인 깃 커밋 메세지를 작성하는 방법에 대해 살펴본다.
2. 커밋 메세지의 7가지 규칙
제목과 본문을 빈 행으로 구분한다.
제목을 50글자 이내로 제한한다.
제목의 첫 글자는 대문자로 작성한다.
제목의 끝에는 마침표를 넣지 않는다.
제목은 명령문으로 작성하고 과거형을 사용하지 않는다.
본문의 각 행은 72글자 내로 제한한다.
어떻게 보다는 무엇과 왜를 설명한다.
3. 커밋 메세지의 구조
타입(Type): 제목(Subject)본문(Body)꼬리말(Footer)
3-1. 타입(Type): 제목(Subject)
타입(Type)은 해당 커밋의 성격을 나타낸다. 타입(Type)의 종류는 아래와 같다.
feat: 새로운 기능 추가
fix: 버그 수정
build: 빌드 관련 파일 수정
ci: ci관련 설정 수정
docs: 문서 추가, 수정, 삭제
style: 스타일(코드 형식, 세미콜론 추가 등과 같은 비즈니스 로직에 변경 없는 경우)
refactor: 코드 리팩토링
test: 테스트 코드 추가, 수정, 삭제
chore: 기타 변경사항
제목(Subject)은 커밋 메세지를 대표한다. 간결하고 2. 커밋 메세지의 7가지 규칙에 맞게 작성한다.
타입(Type): 제목(Subject) 예시
feat: 학생의 알러지를 검사하는 함수 추가
3-2. 본문(Body)
선택사항이며 제목에서 생략한 상세한 내용을 작성한다.
설명뿐만 아니라, 커밋의 이유를 작성할 때에도 쓴다.
본문(Body) 예시
feat: 학생의 알러지를 검사하는 함수 추가
식단표의 알러지 보기 기능을 추가하기 위한 함수 추가
3-3. 꼬리말(Footer)
선택사항이므로 모든 커밋에 꼬리말을 작성하지 않아도 된다.
issue tracker ID를 작성할 때 사용한다.
해결: 이슈 해결 시 사용
관랸: 해당 커밋에 관련된 이슈 번소
참고: 참고할 이유가 있는 경우 사용
꼬리말(Footer) 예시
feat: 학생의 알러지를 검사하는 함수 추가
식단표의 알러지 보기 기능을 추가하기 위한 함수 추가
참고: #123
4. 규칙적인 깃 커밋 메세지의 이점
팀원과의 원활한 소통
편리한 과거의 기록 추적
이슈와 관련된 진행 사항 확인
5. ETC - 리팩토링
feat과 refactor을 구분하기 위해 추가적으로 공부한 내용을 정리한다.
5-1. 리팩토링을 해야 할 때
The Rule Of Three: 유사한 내용이 세번 이상 반복할 때
새로운 기능을 추가할 때
현재 소스코드에서 새로운 기능을 추가하기 어려워 보이면, 리팩토링을 한다.
코드리뷰를 할 때
5-2. Two Hats
Two Hats
기능을 추가할 때: 기존코드를 수정하지 말고, 기능과 테스트만 추가
리팩토링을 할 때: 기능과 테스트를 추가하지 않기
리팩토링을 하면서 기능을 추가하는 것이 아니라 기능단위로 추가, 테스트 후 리팩토링을 해야한다.
6. Conclusion
지금까지 많은 커밋 메세지를 작성했었다. 하지만 어떤 규칙이 없었으며 기능 단위로 하지도 않았다. 즉, 내가 하고 싶을 때마다 했다. 그래서 어떤 코드가 변경이 되었는지 과거를 거슬러 올라가야 할 필요가 있을 때 하나하나 찾아봐야해서 시간이 많이 걸렸다. 물론 지금까진 주로 혼자서만 프로젝트를 진행했기 때문에 큰 문제는 없었다. 앞으로 개발자가 되어 동료들과 함께 프로젝트를 진행하게 될 텐데 미리 규칙적인 커밋 메세지를 작성하는 방법을 숙지해야 겠다. 그리고 티처캔에도 도입을 해봐야겠다.
위의 내용은 구글링을 통해 널리 사용되고 있는 커밋 메세지 작성 방법으로 보인다. 이보다 더 중요한 건 이후에 내가 들어갈 팀에서 정한 규칙이다.
