📢 팀 프로젝트 머지 규칙(Merge Rule) 표준 적용 안내

[frydaynar]

✅ Merge Rule (머지 규칙)

1. 도입 배경 및 목적

• 코드 품질 검증
• 모든 코드는 병합 전 동료의 검토를 거쳐 잠재적 오류를 최소화합니다.
• 메인 브랜치 보호
  안정성이 확인된 코드만 main 브랜치에 반영하여 서비스 신뢰도를 확보합니다.
• 협업 일관성
  공통 플랫폼의 운영 원칙을 팀 프로젝트에 그대로 이식하여 협업 효율을 극대화합니다.

2. 핵심 머지 규칙 (Merge Rules)

실무형 개발 운영을 위해 다음 규칙을 엄격히 준수합니다.

• main 직접 Push 금지
  모든 변경 사항은 반드시 Pull Request(PR)를 통해서만 반영될 수 있습니다.
• 리뷰 없는 Merge 금지
  최소 1인 이상의 팀원의 승인(Approve) 이 있어야 병합이 가능합니다.
• 충돌 해결 책임
  Merge 시 발생하는 코드 충돌은 PR 작성자(작업 담당자) 가 직접 해결하는 것을 원칙으로 합니다.
• 브랜치 즉시 삭제
  Merge가 완료된 작업 브랜치(feature/*, update/* 등)는 저장소 관리를 위해 즉시 삭제합니다.

3. PR & Merge 프로세스

작업 완료 후 병합까지의 표준 절차는 다음과 같습니다.

1. PR 생성
   기능 단위 작업 완료 후, UI 화면 동작 검증(Frontend) 또는 API 정상 동작 및 핵심 로직 검증(Backend/AI)을 마친 뒤 PR을 생성합니다. (미완성 기능 PR 지양)
2. 템플릿 준수
   PR 작성 시 지정된 PR Template을 사용하며, 주요 변경 사항 및 리뷰 포인트를 상세히 기록합니다.
3. 이슈 연결
   Closes #Issue번호 형식을 사용하여 해당 작업과 연관된 이슈가 자동으로 닫히도록 설정합니다.
4. 리뷰 및 수정
   리뷰어의 피드백을 반영하여 코드를 수정한 후 재요청합니다.
5. 최종 병합
   모든 승인이 완료되면 최종 확인 후 dev 및 main 브랜치에 통합합니다.

4. 최종 권한 및 운영

• 최종 머지 권한
  팀 프로젝트의 안정적인 통합을 위해 팀장(@HorieZA) 이 최종 확인 후 dev 및 main 브랜치 병합을 담당하며, 부재 시 본인 외 팀원(@mpsddd-commits, @frydaynar) 이 대행합니다

5. PR 템플릿 (PR Template)

## #️⃣ 연관된 이슈
Closes #Issue번호

## 📝 작업 내용
변경 사항을 간략히 적어주세요.

## 💬 리뷰 요구사항(선택)
집중적으로 봐줬으면 하는 부분이나 논의가 필요한 점.

---

📎 관련 근거 및 문서

• [공지] 프로젝트 협업을 위한 GitHub Ground Rule 및 워크플로우 (v1.3)
• [WITH] 프로젝트 GitHub 협업 및 운영 가이드 (v1.3)

우리 팀은 "검토되지 않은 변경은 팀 자산이 될 수 없다" 는 운영 원칙을 바탕으로 움직입니다.
특히 전 파트 간의 긴밀한 화면 및 API 연동이 필수적인 M3 단계인 만큼, 서로의 코드를 꼼꼼히 리뷰하여 완성도 높은 시스템을 만들어 주시기 바랍니다.

[mpsddd-commits]

확인했습니다