오늘 실시간 강의를 들으면서 Conventional Commits에 대해서 알게 되었다. 평소 git을 다른 팀원간의 협업보다 개인 레포지토리에 push를 하는 나로서는 commit의 메시지를 크게 신경쓰지 않았지만 이 Conventional Commits을 알고나서 앞으로는 커밋을 할 때 좀 더 신경을 써야겠다.
이 글은 Conventional Commits 와 NKLCB-git을 참고해 필요한 부분을 정리하여 작성된 글입니다.
📌 개요
Conventional Commits 스펙은 커밋 메시지에 곁들여진 가벼운 컨벤션으로 명확한 커밋 히스토리를 생성하기 위한 간단한 규칙을 제공한다. 이렇게 만들어진 커밋 히스토리를 이용하여 더 쉽게 자동화된 도구를 만들 수 있다. 그 결과 이 컨벤션은 커밋 메시지에 신규 기능 추가, 문제 수정, 커다란 변화가 있음을 기술함으로써 유의적 버전(Sementic Versioning) 과 일맥상통한 면이 있다.
이 Conventional Commits에서 말하는 커밋 메시지의 구조는 다음과 같아야 한다고 주장한다.
<타입>[적용 범위(선택 사항)]: <설명>
[본문(선택 사항)]
[꼬리말(선택 사항)]의도를 전달하기 위해 다음과 같은 구조적 요소가 포함되어 있다.
1. fix: 코드베이스에서 버그를 패치하는 fix 타입의 커밋
2. feat: 코드베이스에서 새 기능이 추가 되는 feat 타입의 커밋
3. BREAKING CHANGE: 본문이나 꼬리말의 시작 부분에 BREAKING CHANGE: 이라는 문자열을 가진 커밋은 커다란 API 변경이 있다는 것을 의미 함
4. 다른타입: fix:와 feat: 이외의 타입을 말하고 아래는 앵귤러 컨벤션을 기반으로 하는 타입들
feat: features (기능 개발 관련)
docs: documentations (문서화 작업)
conf: configurations (환경설정 관련)
test: test (test 관련)
fix: bug-fix (오류 개선 혹은 버그 패치)
refactor: refactoring
ci: Continuous Integration
build: Build (빌드 관련)
perf: Performance새로운 기능이나 버그 수정 없이 현재 구현체를 개선하는 커밋에 대해서는 improvement 사용을 권장
commit 할 때 기억해야할 것
- commit은 동작 가능한 최소단위로 자주 할 것.
- 해당 작업단위에 수행된 모든 파일 변화가 해당 commit에 포함되어야 함.
- 모두가 이해할 수 있는 log를 작성할 것.
- Open Source Contribution시 영어가 강제되지만, 그렇지 않을 경우 팀 내 사용 언어를 따라 쓸 것.
- 제목은 축약하여 쓰되(50자 이내), 내용은 문장형으로 작성하여 추가설명 할 것.
- 제목과 내용은 한 줄 띄워 분리할 것.
- 내용은 이 commit의 구성과 의도를 충실히 작성할 것.
📌 예제
본문에 설명과 BREAKING CHANGE를 가지는 커밋 메시지
chore!: drop Node 6 from testing matrix
BREAKING CHANGE: dropping Node 6 which hits end of life in April본문이 없는 커밋 메시지
docs: correct spelling of CHANGELOG적용 범위를 가지는 커밋 메시지
feat(lang): add polish language옵션이 이슈 번호를 가진 fix 타입의 커밋 메시지
fix: correct minor typos in code
see the issue for details on the typos fixed
closes issue #12커밋 컨벤션 예제
feat: Create server.py to start flask project
docs: Create README.md
conf: poetry init
test: User model CRUD test complete📌 Conventional Commits을 사용하는 이유
- CHANGELOG를 자동으로 생성하기 위해서
- (포함된 커밋의 타입에 기반하여) 유의적 버전을 자동으로 변경하기 위해서
- 팀 동료, 타인, 그리고 기타 이해당사자에게 변화의 본질을 전달하기 위해서
- 빌드와 배포 프로세스를 수행하기 위해서
- 더 구조화된 커밋 히스토리를 보여줘서 사람들이 프로젝트에 기여하기 더 쉽도록 하기 위해서
오픈소스에 기여하거나 앞으로 기여할 예정인 사람들은 Conventional Commits을 알아두면 좋을 것 같다.
