Branch

<branch type>/<issue number>

<aside> 💡 ex) feat/#12

</aside>

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

main 브랜치를 중심으로 기능 구현시, 필요한 경우에 rebase를 이용해 덧붙여 나가는 방식, 브랜치는 3가지만 갖고 가는 것으로 정한다.

Commit

Commit Message 형식

<commit type>: <description>

<aside> 💡 ex)

• feat: add user model

• fix: null exception handling

• chore: build 17 </aside>

• commit type 종류 - “Good”

  • feat : 새로운 기능 추가
  • fix : 버그 수정
  • docs : 문서 수정, 주석 추가
  • style : 코드 변경이 없는 코드 포맷팅
  • refactor : 코드 리펙토링
  • chore : 빌드 업무 수정, 패키지 매니저 수정
  • test : 테스트 코드, 리펙토링 테스트 코드 추가
  • design : 사용자 UI 디자인 변경
  • rename : 파일 혹은 폴더명 수정
  • remove : 파일 혹은 폴더 삭제

• description

  • 커밋에 대한 설명을 적어주시면 됩니다.
  • 동사를 앞에 두고 모두 소문자로 작성

• body, footer

  • 작성하지 않음

Pull Request

• 리뷰할 코드 단위 정하기
• 기본 브랜치는 dev 브랜치이며, 특정한 이슈와 관련된 브랜치를 생성하는 경우에 다음과 같은 생성 규칙을 적용하여 만들고, PR을 올린다.
  • 브랜치의 앞에는 이슈 유형(label이 붙은 것)이며, 다음으로는 이슈 번호를 붙인다. (내부 기능이나 정보는 작성하지 않는다) ex) feat/#27
  • 하나의 브랜치에는 하나의 이슈만 해결한다.
• PR의 제목은 [#이슈번호] 주요한 기능 으로 설정한다. (주요한 기능을 찾기 어렵다면, 이슈 title로 설정한다.)
  • ex) [#23] 메인 컴포넌트 분리
• Pull Request를 올리는 경우에, PR 템플릿을 사용하여 형식에 맞게 등록한다. 또한 적절한 label을 등록한다.
  • PR 템플릿
• Reviewer에 자신의 팀을 등록하고, Assignee에 자신을 등록한다.
  • 기본적으로는 자신의 분야 팀원만 리뷰어로 등록
  • 추가적으로 필요하다고 판단 시 Assignee이 리뷰어 추가적으로 등록
• 아직 작업중이지만 중간 리뷰 등의 이유로 미리 날린 PR의 경우 Draft로 설정한다.
• Request changes가 없어야 하고, 리뷰가 요청된 리뷰어 중 최소 1명의 Approval 이후에 merge 하도록 진행한다. (단 Pull Request를 올리고, 혹은 다시 리뷰 요청을 한 이후 2일이 경과하여도 추가적인 리뷰가 없는 경우에 merge한다.)
  • 누군가 Approve를 했어도, 누군가 Request changes를 남겼다면 merge하지 않고 해결한 뒤 다시 리뷰를 요청해야 한다.
  • 리뷰어를 등록한 이후에는, 디스코드에서 리뷰 요청을 하는 메시지를 멘션을 걸어서 남긴다.