브랜치 전략

기본적으로 PR을 통해서만 커밋을 추가할 수 있다. 하나의 브랜치는 하나의 기능만 수행하도록 한다.

• main
  • production에 배포하는 브랜치
  • 긴급한 상황 외에는 직접 main으로 커밋하지 않는다.
• development
  • dev에 배포, 테스트를 위한 브랜치
• feature
  • epic 단위 브랜치 (ex. 배송비 설정)
  • epic/branch-name-in-kebab-case
    • ex. epic/shipping-fee
  • 작업이 끝나면 development에 머지, 배포에서 테스트한다.
• 세부 feature
  • 스토리 또는 에픽의 하위 feature 브랜치 (ex. 판매자 - 상점 설정에서 배송비 설정)
  • [jira issue #]-branch-name-in-kebab-case
    • ex. REE-763-shipping-fee-setting

커밋 메세지 컨벤션

• 해당 작업에 대해 구체적인 내용을 담는다
• 앞쪽에 prefix를 붙인다. prefix의 종류는 다음과 같다.
  • feat: 사용자가 인식할 수 있는 기능 변경이 있는 경우 (UI, UX, 기능, 사용자가 보는 문구)
    • ex. feat:#001 - 에러 처리 토스트 추가
  • refactor: 기능 변경은 없고, 내부적인 코드, 파일, 폴더 구조만 변경되는 경우
    • ex. refactor:#001 - 배송비 최대 금액 상수화
  • style: 기능 변경은 없고, 코드 스타일만 변경되는 경우 (들여쓰기 같은 포맷이나 세미콜론 수정)
    • ex. style:#001 - 사용하지 않는 불필요한 태그 제거
  • fix: 버그나 에러 등 문제로 인해 변경되는 경우
    • ex. fix:#001 - input이 사라지는 이슈 수정
  • test: test 관련한 코드의 추가, 수정
    • ex. fix:#001 - 장바구니 목록 확인 테스트 케이스 작성
  • chore: eslintrc, README.md 등 설정 파일 수정이나 주석을 다는 경우
    • ex. chore:#001 - 주석 추가