커밋과 버전관리의 숨겨 왔던 진실

728x90

버전관리처럼 커밋 메세지도 명확한 규칙이 있다는 사실! ⚒

표기하는 법과 툴만 다를 뿐, 본질은 같습니다

커밋 메시지에 곁들여진 가벼운 컨벤션

명확한 커밋 히스토리를 생성하기 위한 간단한 규칙을 제공

커밋 메세지에 신규기능 추가, 문제 수정, 커다란 변화가 있음을 기술함으로써 유의적 버전과 일맥상통한 면이 있습니다.

**<타입>** [적용범위(선택사항)] : **<설명>**

[본문(선택사항)]

[꼬리말(선택사항)]

fix → 버그수정에 대한 커밋 patch
feat → 새 기능 추가에 대한 커밋 minor
BREAKING CHANGE → 커다란 API 변경이 있다는 의미로 본문이나 꼬리말 시작부분에 씁니다. major
- BREAKING CHANGE 는 커다란 수정이 있다는 의미, 본문이나 꼬리말 부분에 쓰이기 때문에 명시할 때 <타입> ! : <설명> 처럼 ! 표시를 넣어줘야 합니다. → 큰 변화에 대한 주의를 줍니다.
build→ 빌드 관련 파일 수정에 대한 커밋
chore→ 그 외 자잘한 수정엥 대한 커밋
ci→ CI 관련 수정에 대한 커밋
docs→ 도큐먼트 수정에 대한 커밋
style→ 코드 문법 또는 포맷에 대한 수정에 대한 커밋
refactor→ 코드 리팩토링에 대한 커밋
test→ 테스트 코드 수정에 대한 커밋

모든 커밋은 feat, fix 와 같은 명사로 된 접두어를 포함해야 하고 그 뒤로 옵션인 적용범위, 그리고 필수인 : 과 공백이 있어야 합니다.
설명은 타입/적용 범위 접두어 뒤에 있는 공백 다음에 작성되어야 합니다. 설명은 코드 변경 사항에 대한 짧은 요약입니다.
대소문자 구분은 없지만 일관되게 사용하는 것이 좋습니다.

728x90