프로젝트 규칙 - GagiMarket/gagi GitHub Wiki

Rule: Git Convention

  • 기능(feat): 새로운 기능을 추가
  • 버그(fix): 버그 수정
  • 리팩토링(refactor): 코드 리팩토링
  • 형식(style): 코드 형식, 정렬, 주석 등의 변경(동작에 영향을 주는 코드 변경 없음)
  • 테스트(test): 테스트 추가, 테스트 리팩토링(제품 코드 수정 없음, 테스트 코드에 관련된 모든 변경에 해당)
  • 문서(docs): 문서 수정(제품 코드 수정 없음)
  • 기타(chore): 빌드 업무 수정, 패키지 매니저 설정 등 위에 해당되지 않는 모든 변경(제품 코드 수정 없음)

소문자로 작성하고 다음과 같은 형태로 작성한다. ex) feat: 상품 기능 API 구현

총 글자 수는 50자 이내며 마지막에 마침표(.)를 붙이지 않는다.

Rule: Git Branch

브랜치는 아래와 같이 관리한다.

  • {원본 저장소}/main: 제품 출시 하는 메인 브랜치
  • {원본 저장소}/develop: 다음 출시 버전을 개발하는 브랜치
  • {개인 원격 저장소}/main
  • {개인 원격 저장소}/develop
  • {개인 원격 저장소}/feature/{issue number}: 기능 개발을 위한 브랜치

기능 개발을 위한 브랜치(feature)의 경우에 다음과 같은 형태로 생성한다. /feature/{issue number}

Rule: Git issue

issue 제목은 타입: 이슈 내용 형태로 작성한다.

ex) feat: 상품 기능 API 구현

Rule: Pull Request & Merge

{개인 원격 저장소}/feature/{issue number}에서 기능을 구현하고 {원본 저장소}/develop 브랜치로 Pull Request를 생성한다.

즉, {원본 저장소}/develop <----PR----- {개인 원격 저장소}/feature/{issue number}

Pull Request의 제목은 issue 제목과 일관되게 타입: 이슈 내용 형태로 작성한다.

ex) feat: 상품 기능 API 구현

이와 같이 하는 이유는 PR 후 Merge 할때 일관된 커밋 로그를 남기기 위함이다.

코드 리뷰 이후 최종적으로 PR을 Merge할때 3가지 Merge 옵션 중 Squash and merge를 선택하여 Merge를 수행한다.

Rule: 문서화

commit convention: docs: {message}

  1. 개인 로컬 저장소(branch: develop 로 맞춘다)
  2. README 작성
  3. 개인 원격 저장소 push
  4. 원본 저장소로 PR (GagiMarket/gagi/develop ← {개인 깃 계정}/gagi/develop)
  5. 리뷰 & merge