팀 워크에서 가장 중요한 것은 같은 언어로 이야기해야하는 것이라고 생각합니다.
같은 언어로 이야기 한다는 것은 의미를 해석하는 시간을 줄여 생산성을 높이기 위함이라고 생각하는데요.
그렇기 때문에 회사에서 convention에 신경을 쓰는 편입니다.
하나 딱! 정해놓고 평생동안 울궈먹거나 이것을 기준삼아 발전시키기 위해 개인적으로 정리해보았습니다.
Commit Formats
Default
<type>(<optional scope>):<subject>empty separator line<optional body>empty separator line<optional footer>subject와body에는 한글/영어를 혼용이 가능한 것으로 하겠습니다.- 혹시 팀원 전원이 찬성한다면
subject와body역시 영어를 사용하는 것을 권장합니다.
Types
Type을 통해 해당 커밋의 가장 기본적을 목적을 파악합니다.
feat: 기획과 관련한 기능 추가 및 삭제fix: 버그 수정 및 기존 기능 수정refactor: 리팩토링 (기능 수정 X) * 기능 수정과 리팩토링 구분해서 올려주세요.perf: 성능 향상을 위한 리팩토링
style: code style 변경 (white-space, formatting, missing semi-colons, etc)test: 테스트 추가docs: 문서 추가/변경 (ReadMe.md)build: 빌드 관련 변경 (build tool, ci pipeline, dependencies, project version)chore: 그외 변경 (.gitignore)
Scope
scope는 하나의 repo에 다양한 앱이 있을 경우 구분을 짓기 위함입니다.
- request과 response이 있다면
fix(request): fix typo,feat(response): fix typo - 비지니스 로직을 구분하기 위해서 사용
Subject
subject에서는 좀더 명확한 변경 내용을 담습니다.
- required
- 59자 이하로 작성해주세요.
추가,변경,수정,삭제,개선등 명사형 문장으로 작성- 영문의 경우 명령형으로 작성
- 끝에 온점(.) 생략
- 파일명이나 함수명은 사용 X (코드에서 보여줄것임)
- ex) oo 기능 추가, 불필요한 코드 삭제
Body
- optional
- 한 줄에 59자 이하
추가,변경,수정,삭제,개선등 명사형 문장으로 작성- subject 외 자세한 내용이 필요하다면 작성
Examples
feat: 엄청난 버튼 추가fix: <어떤 이유>인한 oo 컴포넌트 버그 수정fix: 오타 수정build: package.json dependency 업데이트refactor: oo 컴포넌트 구조 리팩토링style: white space 제거
Todo
BREAKING CHANGES나 이슈번호를 남기는 방법에 대해서 이해하기- commitlint 적용하기
- 좀더 실무적인 예시 추가하기
References
