.gitmessage.txt

# <타입(<영역>)>: <주제>
#  - 타입은 필수 작성. 해당 커밋의 성격을 나타내며 타입의 종류 중 하나만 선택, 영어 대문자로 시작
#  - 영역은 필요 시 작성. 변경된 부분을 직접적으로 나타냄 ex) Refactor(MemberService): loginMember 메소드 명을 login으로 수정
#  - 주제는 필수 작성. 최대 50글자까지, 끝에 마침표 금지, 한글로 간단 명료하게 작성, 현재형 사용
# 바로 밑줄에 작성

# 바로 아래 한 줄 공백 유지 (머릿말과 본문의 분리를 위함)

################################
# <본문> - 필요시 작성. 한 줄당 최대 72자까지, 72자 초과시 줄바꿈, ”왜”, “무엇을 위해” 작업했는지에 초점을 맞춰 작성
# 본문에 여러가지 항목이 있다면 글머리 기호나 숫자를 통해 가독성 높이기
# - 변경 내용 1
# - 변경 내용 2
# 1. 변경 내용 1
# 2. 변경 내용 2
# 바로 밑줄에 작성

# 바로 아래 한 줄 공백 유지 (본문과 바닥글의 분리를 위함)

################################
# <바닥글> - 필요시 작성
# 바로 밑줄에 작성 (이슈 해결 시에는 resolve: #99와 같이 작성)

#######🆁🅴🅼🅴🅱🅴🆁 🅼🅴######
# [타입 리스트]
#  Feat: 새로운 기능을 추가한 경우(기능 추가)
#  Fix: 올바르지 않은 동작(버그)을 고친 경우
#  Docs: 문서를 추가, 수정한 경우
#  Style: 내부 로직은 변경하지 않고 코드 스타일, 포맷 등을 수정한 경우, 줄 바꿈, 누락된 세미콜론 추가 등의 작업도 포함
#  Refactor: 내부 로직은 변경하지 않고 기존의 코드를 개선한 경우, 클래스명 수정&가독성을 위해 변수명을 변경한 경우도 포함
#  Chore: 패키지 매니저 수정, 그 외 기타 수정. ex) .gitignore
#  Design: CSS 등 사용자 UI 디자인 변경
#  Remove: 파일을 삭제하는 작업만 수행한 경우
#  Comment: 필요한 주석 추가 및 변경
#  Rename: 파일 또는 폴더 명을 수정하거나 옮기는 작업만인 경우
#  !BREAKING CHANGE: 커다란 API 변경의 경우
#  !HOTFIX: 급하게 치명적인 버그를 고쳐야 하는 경우
#  Test: 테스트 코드를 추가, 수정, 삭제한 경우
# ------------------
# [커밋 메시지 예시]
#  Fix: CardList 컴포넌트 클릭 시 공백으로 나오는 오류 수정
#
#  모바일 버전에서 CardList의 img 부분 클릭 시 공백으로 나오는 오류 수정.
#  PC 버전은 이상 없음.
#
#  resolve: #232
# ------------------
# [우리 팀이 지켜야 할 보편적 규칙]
#  1. 언어는 한국어를 사용한다.
#    - 예외 사항) 최초 커밋 메시지는 “Initial commit”으로 한다.
#  2. 문장의 구성
#    1) 문장은 간결하게 구성한다.
#    2) 현재형을 사용한다.
#  3. 작성한 당사자가 아닌 제 3자가 이해할 수 있도록 작성한다.
#  4. 단순한 문장일수록 좋다.
# ------------------
# [우리 팀의 커밋 타이밍]
#  - 의미 있는 코드의 변화가 있다면 커밋을 진행한다.
#  - 의미가 있다면 사소한 것을 커밋 하는 것은 전혀 잘못된 것이 아니다.
#  - 다만 의미 없는 잦은 커밋은 히스토리 추적에 불편함을 주므로 의미 없는 커밋은 자제한다.
################################