Pull Request Convention

GitHub Flow

• main 브랜치 (default)

  • main 브랜치는 배포 가능한 상태만을 관리하는 브랜치
  • 배포 가능한 상태의 코드만을 관리하는 프로덕션용 브랜치
  • PM(양재서)의 승인 후 병합 가능
    • 기능 추가와 관련된 PR에 대해 반드시 리뷰어 등록
    • MVP release 이후에는 모든 PR에 대해 리뷰어 등록

• 작업 브랜치

  • 티켓이 포함된 작업은 {티켓번호}-{브랜치명}로 브랜치 명을 작성한다.
    • feat/{티켓번호}-{브랜치명}: 신규 기능 개발 시 브랜치명
    • fix/{티켓번호}-{브랜치명}: 수정 작업 시 브랜치명
    • refactor/{티켓번호}-{브랜치명}: 리팩토링 작업 시 브랜치명
    • hotfix/{티켓번호}-{브랜치명}: 빠르게 수정해야 하는 버그 조치 시 브랜치명
  • 티켓이 포함되지 않은 작업은 명확한 브랜치명을 작성한다.
    • fix/{브랜치명}
    • hotfix/{브랜치명}

Pull Request Title Convention

• Document(📑): 문서 작업을 진행하였을 경우 ex) 📑 React 버전 업데이트
• Setting(⚙️): 세팅과 작업을 진행하였을 경우 ex) ⚙️ CI/CD 파이프라인 구축
• Feature(✨): 새로운 기능을 추가하였을 경우 ex) ✨ 피드 메인 페이지 UI 구축 및 API 연결
• Fix(🛠️): 어떠한 기능에 대한 수정을 하였을 경우 ex) 🛠️ 피드 메인 API 로직 수정
• UI(🎨): UI 작업만을 진행하였을 경우 ex) 🎨 피드 메인 페이지 UI 추가/수정
• Feedback(💻): 스프린트 시연간에 있었던 피드백을 반영하는 경우 ex) 💻 피드 메인 페이지 피드백 반영
• Refactor(⚡): 리팩토링하였을 경우 ex) ⚡ 피드 관련 API 로직 리팩토링

Pull Request Review Convention

리뷰어는 P1부터 P5까지의 단계로 리뷰를 작성하고, 작성자는 각 단계에 알맞게 대응해야합니다.

• P1: 꼭 반영해주세요 (Request changes)
  • 리뷰어는 PR의 내용이 서비스에 중대한 오류를 발생할 수 있는 가능성을 잠재하고 있는 경우, P1 태그를 통해 반드시 수정해야 한다고 요청합니다.
  • 작성자는 리뷰어의 요청을 반영하거나, 반영할 수 없는 합리적인 이유를 제시하여 설득해야 합니다.
• P2: 적극적으로 고려해주세요 (Request changes)
  • 작성자는 수정 요청에 대해서 적극적으로 고려하며, 수용하거나 적합한 의견을 통해 토론하여 리뷰어를 설득해야 합니다.
• P3: 웬만하면 반영해 주세요 (Comment)
  • 작성자는 P3에 대해 수용하거나, 수용할 수 없는 상황이라면 그 이유를 설명하거나, Issues 등록 혹은 Jira 티켓으로 반영할 계획을 명시적으로 표현해야 합니다.
• P4: 반영해도 좋고 넘어가도 좋습니다 (Approve)
  • 작성자는 반영하는 것을 고민해 보되, 무시해도 괜찮습니다.
• P5: 그냥 사소한 의견입니다 (Approve)
  • 무시해도 되는 간단한 의견입니다. 간단한 질문이나 칭찬의 경우 이 단계로 작성합니다.