깃 컨벤션

Branch

<branch type>/<issue number>

💡ex) feat/#12, fix/#132 ...

• Branch type

  • feat : 기능 브랜치
  • fix : 오류 수정 브랜치
  • refactor : 리팩토링 브랜치

• main 브랜치를 중심으로 기능 구현한다.

• 필요한 경우에 rebase를 이용해 덧붙여 나간다.

• 브랜치는 3가지만 갖고 가는 것으로 정한다.

Commit

<commit type> : <description>

💡ex) feat: add user model, fix: null exception handling, chore: build 17 ...

• Commit type
  • feat : 새로운 기능 추가
  • fix : 버그 수정
  • docs : 문서 수정, 주석 추가
  • style : 코드 포맷팅, 코드 변경이 없는 경우
  • refactor : 코드 리펙토링
  • chore : 빌드 업무 수정, 패키지 매니저 수정
  • test : 테스트 코드, 리펙토링 테스트 코드 추가
  • design : 사용자 UI 디자인 변경
  • rename : 파일 혹은 폴더명을 수정하는 경우
  • remove : 사용하지 않는 파일 혹은 폴더를 삭제하는 경우
• description
  • 커밋에 대한 설명을 작성한다.
  • 동사를 앞에 두고 모두 소문자로 작성한다.
• body, footer
  • 작성하지 않는다.

Pull Request

• 기본 브랜치로는 dev 브랜치를 사용한다.

• 특정한 이슈와 관련된 브랜치를 생성하는 경우에 생성 규칙을 적용해 PR을 올린다.

  • 브랜치의 앞에는 이슈 유형(label이 붙은 것)이며, 다음으로는 이슈 번호를 붙인다.
  • 하나의 브랜치에는 하나의 이슈만 해결한다.

• PR의 제목은 [#이슈번호] 주요한 기능 으로 설정한다. (주요한 기능이 없다면, 이슈의 title로 설정한다.)

  💡ex) [#12] add user model, [#132] null exception handling ...

• 생성 규칙에 맞게 등록하며 적절한 label을 등록한다.

  ## Issue
  
  -
  
  ## Description
  
  -
  
  ## Check List
  
  - [ ] PR 제목을 커밋 규칙에 맞게 작성
  - [ ] PR에 해당되는 Issue를 연결 완료
  - [ ] 적절한 라벨 설정
  - [ ] 작업한 사람 모두를 Assign
  - [ ] 작업한 팀에게 Code Review 요청 (Reviewer 등록)
  - [ ] "main" 브랜치의 최신 상태를 반영하고 있는지 확인
  
  ## Screenshot

• Reviewer에 자신의 팀을 등록하고, Assignee에 자신을 등록한다.

  • 기본적으로는 자신의 분야 팀원만 Reviewer로 등록한다.
  • 필요하다고 판단 시 Reviewer를 추가적으로 등록한다.

• 아직 작업중이지만 중간 리뷰 등의 이유로 미리 날린 PR의 경우 Draft로 설정한다.

• Request changes가 없고 리뷰가 Reviewer 중 최소 1명의 Approval 이후에 merge를 한다.

  • Pull Request를 올리고 2일이 경과하여도 추가적인 리뷰가 없는 경우에는 그냥 merge한다.
  • 누군가 Request changes를 남겼다면 merge하지 않고 해결한 뒤 다시 리뷰를 요청한다.
  • 리뷰어를 등록한 이후에는, 디스코드에 리뷰 요청을 하는 메시지를 남긴다.

• 모든 PR은 설정해 놓은 Checks를 모두 성공해야 한다.

  • PR을 통해 main 브랜치에 merge 하는 경우에는, squash merge를 사용하여 merge한다.

• merge를 완료한 branch는 삭제한다.

• PR 등록 시 본인의 코드를 스스로 리뷰한다.

  • 중점적으로 생각하는 부분, 본인이 생각하기에 리뷰가 필요한 부분 등을 표시한다.

• 나중에 작업할 부분은 코드 내부에 TODO 로 명시한다.