Skip to content

커밋 컨벤션

Jump to bottom
Yongjun Park edited this page Oct 7, 2023 · 4 revisions

들어가며

  • Conventional Commits v1.0.0를 따르고 있어요.
  • 가능한 한 작은 단위로 커밋해주세요.
  • 커밋을 작성하면 그 커밋에서 설명한 내용을 이루는데 필요한 변경만 들어있어야 해요. 필요하지 않은 변경이 들어있다면 다른 커밋으로 분리해주세요.

Best Practice

이해를 돕기 위해 컨벤션 설명 전에 예시부터 보여드릴게요.

ex. 제목 줄만 있는 커밋

feat(team): 자동 평가 카드 추가

ex. 제목 줄과 꼬리글이 있는 커밋

feat(team): 자동 평가 카드 추가

Close #210, #211
See also #149

ex. 제목 줄, 본문, 꼬리글 모두 있는 커밋

feat(team): 자동 평가 카드 추가

Moulinette의 자동 평가를 유저 평가 아래에 추가하였습니다. 
자동 평가에는 flag가 존재하지 않기 때문에 EvalLogListItem의 flag를 Optional로 변경하였습니다. 

Close #210, #211
See also #149

용어 정리

type(scope): subject

Body

Footer
영어 한글
type 타입
scope 범위
subject 제목
body 본문
footer 꼬리말

타입

  • 아래의 타입 중 하나를 반드시 사용해야 해요.
타입 설명
feat 새로운 기능
fix 버그 수정
refactor 리팩토링
perf 성능(ex. SEO, 렌더링 최적화)에 영향을 준 리팩토링
design CSS 또는 UI 변경
style 코드 형식 변경 (세미콜론, 줄바꿈 등)
build config 파일 변경, dependency 설치 또는 삭제
ci Github Actions 류 파일의 수정
docs 문서 변경
chore 위 타입에 모두 해당하지 않는 커밋 + move/rename/remove

(아직 쓰지 않았지만 쓸 수 있는 타입)

타입 설명
test 테스트 코드 변경
comment 주석 변경
revert revert 사용
  • 소문자로 시작해야 해요.
  • 깃모지는 붙이지 마세요.
  • 콜론(:) 앞은 붙이고, 뒤는 띄어써야 해요.
  • 많은 코드에 영향을 줄만한 중요한 커밋으로 판단되는 경우, 타입 앞에 !를 붙여주세요.
    • ex. !refactor(folder-structure): folder-by-feature 방식으로 재편
    • ⚠️ !REFACTOR, refactor(folder-structure)! 등의 방식으로 사용하지 마세요.
  • build, ci, docs, comment를 chore로 뭉뚱그려 사용하지 마세요.
  • UI 스타일 변경은 style이 아닌 design 타입을 사용해야 해요.

범위 (선택)

  • 범위를 명시한 경우, 제목에 범위 관련 내용을 다시 언급하지 마세요.
  • 자유롭게 달아도 괜찮아요. 하지만 아래 예시의 case 컨벤션을 지켜주세요.

ex. 코드를 중심으로 범위 명시

  • feat(eval-log-search) : 평가로그 검색기 페이지에서의 기능 추가
  • feat(EvalLogSearchForm) : EvalLogSearchForm 컴포넌트 내에서의 기능 추가
  • feat(handleEvalLogSearchFormSubmit) : handleEvalLogSearchFormSubmit 함수 내에서의 기능 추가

ex. 일의 분야를 중심으로 범위 명시

  • feat(accessibility) : 웹 접근성과 관련된 기능 추가
  • build(deps) : 디펜던시와 관련된 변경

타입이 애매한 상황 예시

feat

유저 기준에서 새로운 기능인지 생각해주세요.

ex. button 요소에 aria-label을 추가하여 웹 접근성을 높였어요

  • feat(accessibility): button 요소에 aria-label 추가
  • SEO와 달리 웹 접근성은 유저 기준에서 새로운 기능이므로 perf보다 feat이 더 적합해요.

ex. 블랙홀 계산기 기능을 삭제했어요

  • feat(blackhole-calculator): 기능 삭제
  • feat: 블랙홀 계산기 삭제
  • 기능 삭제를 refactor, fix 대신 feat로 분류해요.

refactor

ex. 평가로그 검색 폼을 react-hook-form 라이브러리를 이용하는 로직으로 변경했어요

  • refactor(EvalLogSearchForm): react-hook-form 도입
  • feat은 유저 기준에서 새로운 기능일 때 사용해야 해요. 동일 기능에 로직만 변경한 경우 refactor를 사용해주세요.

ex. getIndividualizedMessage 함수에서 사용하는 메시지들을 constants 폴더로 옮겨 상수화했어요

  • refactor(getIndividualizedMessage): 메시지 상수화

perf

ex. GA(Google Analytics)를 HTML에 추가했어요

  • perf: GA 추가
  • 유저 입장에서 GA 추가는 새로운 기능이 아니므로, feat 대신 perf를 사용해주세요.

build

ex. jotai를 설치했어요

  • build(deps): install jotai
  • build(deps): jotai 설치
  • feat, chore 대신 의미가 더 명확한 build를 사용해주세요.

ex. alias path(@/*)를 folder-by-structure 방식에 맞추어 재편하였어요

  • build(tsconfig/paths): @core/*, @shared/* 방식으로 재편

chore

ex. Codegen을 업데이트했어요

  • chore: update codegen

ex. env 서브모듈을 업데이트했어요

  • chore: update submodule env

ex. SearchDialog의 이름을 Spotlight로 변경했어요

  • chore: rename SearchDialog -> Spotlight
  • chore: rename SearchDialog to Spotlight

제목

  • 영어, 한글 중 자유롭게 사용할 수 있어요.
    • 영어의 경우 가능하면 시작을 동사로 하며, 동사를 사용하는 경우 동사원형 및 대문자로 시작해야 해요. (ex. fixes, Fixed → Fix)
    • 한글의 경우 개조식으로 작성해야 해요. (ex. 그동안 뜨지 않았던 자동 평가 정보를 추가하였습니다, 자동 평가 카드를 추가하였음 → 자동 평가 카드 추가)
  • 제목의 끝에 마침표를 붙이지 마세요.

자주 사용하는 동사 예시

영어 한글
add ~ 추가
update 업데이트(갱신)
remove ~ 삭제
fix ~ 고침
change to ~로 변경
reorganize to ~로 개편
implement ~ 구현

본문 (선택)

  • 제목만으로 내용을 충분히 알리지 못했을 때 사용해요. 다다익선!
  • 해당 커밋 이후로 변경되는 사항에 대해 알려주세요. (무엇이 변경되었나)
  • 변경 의도에 대해 충분히 설명해주세요. (왜 변경했나)

꼬리말 (선택)

  • 유형: #이슈번호의 형식으로 사용해요. (BREAKING CHANGE 유형 제외)
  • 여러 이슈번호를 적을 때에는 , (쉼표와 공백)으로 구분해요.
  • 아래의 유형 중 하나를 반드시 사용해야 해요.
유형 설명
Close 이 커밋이 해결한 이슈
See also 참고할 이슈
BREAKING CHANGE 단절적 변경 사항을 알리고 싶을 때

유의할 점

  • 제목 줄과 본문, 본문과 꼬리말 사이에는 각각 하나의 빈 줄이 있어야 해요.
  • wip 커밋이 있는 채로 main 또는 develop 브랜치에 푸시하지 말아주세요. 반드시 PR 올리기 전 squash를 통해 합쳐주세요.
  • PR 시 Rebase and Merge를 이용하기 때문에 Merge pull request ~ 커밋이 추가되지 않아야 해요.
Clone this wiki locally