좋은 커밋 메세지 작성
#좋은 커밋 메세지 작성
netlify로 배포된 박스 오피스의 API_KEY를 숨길 수 있는 방법에 대해 찾아보다가 netlify serverless function을 이용하면 해결할 수 있다는 사실을 알게되었다. 관련 깃허브 레포지토리를 찾았고, 이를 fork하려고 방문했을 때 커밋 메시지가 잘 정리되어있는 것을 보았다. 내가 작성했던 커밋 메시지들과는 다르게 refactor
키워드를 사용하여 변경된 코드 내용을, fix
키워드를 사용하여 오류를 수정한 내용으로 구분하여 작성되어있었다.
이를 보고 좋은 커밋 메세지를 작성해야함의 중요성을 깨달았고, 좋은 커밋 메세지를 작성하는 법을 다룰 예정이다.
가장 좋은 방법은 커밋 메세지에 규칙을 만들어 사용하는 것
로컬스토리지에최근검색어없을때발생하는오류수정
상세페이지수정
node-sass버전오류나서다운그레이드해서재설치
상단의 메세지는 창피하지만 기존에 작성해왔던 커밋 메세지 내용입니다. 규칙이 없어 어떤 작업을 했는지 명확하게 알아 볼 수 없거나 시각적 통일성을 떨어뜨려 커밋 히스토리를 파악하는데 어렵습니다.
일관성 있는 커밋 메세지 규칙을 만들면 과거 코드에 대한 코드 추적이 쉽고, 이슈를 관리하기가 쉬워집니다. 또한 팀원들과의 커뮤니케이션이 쉬워진다는 장점이 있습니다.
좋은 커밋 메세지, 일관성 있는 메세지를 작성하려면 어떤 규칙이 필요할까요?
정답은 네이밍을 명시적이고 규칙적으로 작성해주는 것 입니다. 그리고 해당 커밋의 내용을 자세히게 작성해준다면 코드를 하나하나 분석하지 않아도 해당 커밋의 내용을 알아볼 수 있습니다.
전체적인 커밋 메세지 포맷
1
2
3
4
5
타입(type): 제목(Subject)
본문(body)
꼬리말(footer)
■ 타입 (type)
무엇에 대한 작업인지 키워드를 통해 표시
구분 | 설명 |
---|---|
feat | 새로운 기능 추가 |
fix | 버그수정 |
build | 빌드관련 파일 수정 |
ci | CI 관련 설정 수정 |
docs | 문서(문서 추가/수정/삭제) |
style | 스타일(코드형식,세미콜론 추가; 비즈니스, 로직에 변경 없는 경우) |
refactor | 코드 리팩토링 |
test | 테스트 (테스트 코드 추가/수정/삭제; 비즈니스 로직에 변경 없는 경우) |
chore | 기타 변경사항 (빌드 스크립트 수정 등) |
remove | 파일을 삭제만 한 경우 |
rename | 파일 혹은 폴더명을 수정만 한 경우 |
perf | 성능개선 |
■ 제목 (Subject)
커밋 메세지 제목
- 제목은 50자를 넘기지 않고, 마침표를 붙이지 않는다.
- 제목에 커밋 타입을 함께 작성한다.
- 과거 시제를 사용하지 않고 명령조로 작성한다.
- 제목과 본문은 한줄 띄워 분리한다.
- 제목의 첫 글자는 반드시 대문자로 쓴다.
- 이슈에 관련된 내용이라면 이슈 번호를 붙인다.
#예시
Feat: 관심지역 알림 ON/OFF 기능 추가(#123)
■ 본문 (Body)
커밋 메세지의 본문
- 헤더에서 생략한 상세 내용을 작성한다.
- 선택 사항이므로 모든 커밋에 작성할 필요는 없다.
- 한 줄에 72자를 넘기면 안된다.
- 어떻게(How)보다는 무엇(What), 왜(Why)에 집중하여 내용을 작성한다.
- 설명뿐만 아니라 커밋의 이유를 작성할 때도 작성한다.
#예시
1
2
3
4
Feat: 관심지역 알림 ON/OFF 기능 추가(#123)
시군구의 알림을 각각 ON/OFF 할 수 있도록 기능을 추가함
- opnion0055: 구분 코드
■ 꼬리말 (Footer)
커밋 메세지의 맺음말
- 선택사항이므로 모든 커밋에 작성할 필요는 없다.
- 이슈를 추적하기 위한 ID를 추가할 때 사용한다.
- 해결: 해결한 이슈
- 관련: 해당 커밋에 관련된 이슈ID
- 참고: 참고할만한 이슈
#예시
1
2
3
해결: #123
관련: #321
참고: #222
#커밋 메세지 예시
1
2
3
4
5
6
Feat: 관심지역 알림 ON/OFF 기능 추가(#123)
시군구의 알림을 각각 ON/OFF 할 수 있도록 기능을 추가함
- opnion0055: 구분 코드
해결: #123
참고 사이트