jobmate-frontend

커밋 유형 (Commit Type)

커밋은 다음과 같이 분류하여 메세지를 작성한다.

• feat : 기능 개발
• fix : 버그 수정
• style : css 스타일 수정
• docs : 문서 작업 (주로 main 에서 readme.md 작성)
• refactor : 리팩토링 (기능 변경 없이 아키텍처, 클래스 구조, 함수 추출 등 로직/설계 변경에 집중)
• chore : 파일 옮기기, 파일 이름 변경, 주석 추가 등 단순한 작업
• bulid : 라이브러리 설치

커밋 메세지 작성 규칙

1. 커밋 메세지는 다음과 같은 형태로 작성한다. (띄어쓰기 및 형식 참고)

   [#이슈번호] <커밋 유형> : <커밋 메세지>
   

2. 커밋 메세지는 반드시 한글로 작성한다.

3. 커밋 유형은 반드시 영문 소문자로 작성한다.

4. 필요시, 커밋 메세지의 가장 앞 부분에 이슈 번호를 추가한다.

5. 커밋 메세지는 “논리적으로 독립적인 작업”을 추가 혹은 변경할 때 작성한다

   • 독립적으로 빌드 및 테스트가 가능할 때
   • 롤백시 최소한의 영향을 주는 단위

브랜치 전략 (Branch Strategy)

• main : 배포용 브랜치

  • 실제 서비스에 배포되는 코드만 포함
  • 직접 개발하지 않고 dev 또는 fix 등의 브랜치를 이용하여 병합하여 사용

• dev : 개발 통합 브랜치

  • main 브랜치에서 분기
  • 여러 기능이 개발되고 통합되는 브랜치
  • feature 브랜치에서 작업한 기능들을 이 곳으로 병합
  • 충분히 테스트한 후 main으로 배포

• feature/[기능명] : 신규 기능 개발 브랜치

  • dev 브랜치에서 분기되어 기능 단위로 개발
  • 개발 완료 후 dev로 병합

• fix/[버그명] : 버그 수정용 브랜치

  • dev 또는 release에서 분기하여 버그 수정
    • dev 브랜치에서 분기 : 개발시 발견된 버그 수정
    • 기능 구현에 대한 버그 수정시, 반드시 해당 기능에 대한 브랜치를 병합 후, 분기하여 버그 수정
  • 수정 완료 후 해당 브랜치로 병합

  ex) 회원가입 시 발생하는 오류의 상태 코드를 변경하고 싶음

  → feature/signup 브랜치가 dev와 병합되어 있는지 확인
  
  → dev에서 fix/status-code-error 를 생성하여 버그 수정
  
  → 이후 dev와 병합
  

---

브랜치 규칙 (Branching Rule)

1. 기능 개발은 반드시 feature 브랜치에서 개발

2. 개발 완료 시 dev 브랜치로 합병

   • 브랜치명은 kebab-case 를 사용한다. ex) feature/get-user

3. 모든 QA 및 버그 수정 완료 시 main으로 병합

4. 긴급 수정은 hotfix 브랜치에서 진행 후, 병합