PR 머지 규칙

브랜치 & 머지 대상

• 보호 브랜치: main, develop
  • 이 두 브랜치에는 직접 푸시 금지
  • 반드시 PR 통해서만 머지
• 작업 브랜치: feature/*, chore/* 등
  • 예: feature/user-signup, chore/dev-config

머지 권한 & 승인 기준

• 머지 가능한 사람
  • PR 작성자도 머지할 수 있다 (self-merge 허용).
  • 단, 아래 승인 조건을 모두 만족해야 한다.
• 승인(Review) 기준
  • 최소 2명 이상의 팀원이 Approve한 뒤에만 머지할 수 있다.
  • 2명 Approve가 안 된 상태에서는 누구도 머지하지 않는다.
  • 승인 2명 충족 시, PR 작성자가 직접 머지해도 된다 (self-merge 가능).
• 예외 규칙 (hotfix 등)
  • 정말 긴급한 hotfix의 경우, 팀 합의 하에 “1명 승인 + self-merge”를 허용할 수 있다.
  • 이때는 머지 후 슬랙/노션에 “긴급 머지 이유와 변경 내용”을 반드시 공유하도록 한다.

머지 전략

• 기본 전략: Squash merge
  • feature 브랜치의 여러 커밋을 하나의 커밋으로 합쳐 develop에 머지
• 옵션: main으로의 머지는 필요 시 “Merge commit” 사용

머지 전 체크리스트

• 필수 조건
  • 모든 CI(테스트, 린트 등) 통과
  • 충돌(conflict) 해결 완료
  • 코드 리뷰에서 나온 필수 수정사항 반영
• 권장 사항
  • PR 설명에 “변경 요약 / 주요 변경 파일 / 테스트 방법”이 적혀 있을 것
  • 관련 이슈가 있다면 PR에 링크 (예: Closes #12)