Team Collaboration Rule

🛠️ Team Collaboration Rules

우리 팀의 개발 프로세스와 협업 규칙을 정의합니다. 모든 팀원은 원활한 협업과 코드 품질 유지를 위해 아래 규칙을 준수합니다.

1. Branching Strategy

우리는 GitHub Flow를 기반으로 브랜치를 운용합니다.

📌 Branch Types

• master: 제품으로 배포되는 메인 브랜치입니다. (Direct Push 금지)
• feature/*: 새로운 기능을 개발하는 브랜치입니다.
• hotfix/*: 배포 후 발생한 긴급 버그를 수정하는 브랜치입니다.

📌 Naming Convention

모든 브랜치 이름에는 트래킹을 위해 Jira Issue Key를 반드시 포함합니다.

• feature/[Jira-Key]-[Description]
• hotfix/[Jira-Key]-[Description]

Ex) feature/PROJ-101-login-page

---

2. Jira Integration & Commit Convention

이슈 트래킹과 코드 변경 사항의 연결을 위해 엄격한 컨벤션을 따릅니다.

📌 Commit Message Format

커밋 메시지 헤더에 이슈 키를 포함하여 Jira 티켓과 연동되도록 합니다.

• [Type]-[Jira-Key]: [Description]

Ex) feat-PROJ-101: 로그인 페이지 레이아웃 구현 Ex) fix-PROJ-102: 로그인 버튼 비활성화 오류 수정

📌 Work Rules

• Traceability: 커밋 메시지, PR 제목, 브랜치 이름 등 모든 곳에 Jira Issue Key를 명시합니다.
• Status Management: Jira 티켓의 상태 변경(To Do → In Progress → Done)은 작업자가 수동으로 최신화합니다.

---

3. Pull Request (PR) Process

📋 PR Rules

• 1 PR 1 Feature: 하나의 PR은 하나의 기능 단위로 작성하는 것을 원칙으로 합니다.
• No File Limit: 파일 변경 개수에 제한은 없으나, 리뷰 효율을 고려하여 작성합니다.

📝 PR Template

PR 작성 시 아래 템플릿 양식을 준수합니다.

🚩 What is this PR?

📢 Changes-Detail

📃 Progress Completed:

To-do:

✅ Checklist

[ ] Jira issue key is included

📸 Screenshots or Video

⚙️ Additional Notes

4. Code Review Policy

코드 품질 유지와 안정성을 위해 강도 높은 리뷰 프로세스를 거칩니다.

🛡️ Branch Protection (master)

• Direct Push 금지: 모든 변경사항은 PR을 통해서만 병합됩니다.
• CI Build Check: CI 빌드가 성공해야만 병합(Merge)이 가능합니다.
• Review Requirement: 최소 **2명 이상의 리뷰어 승인(Approve)**이 있어야 병합이 가능합니다.

👁️ Review Focus

리뷰어(Pool: 3명)는 다음 사항을 중점적으로 검토합니다.

1. MVC Pattern: 아키텍처 패턴을 올바르게 준수했는가?
2. Consistency: 기존 코드 스타일 및 구조와 일관성이 있는가?
3. Reusability: 코드의 재사용성을 고려하여 작성되었는가?

---

5. Review Communication Rule (Pn Rule)

리뷰어의 의도를 명확히 전달하기 위해 **Pn 룰(Priority Rule)**을 사용합니다. 코멘트 작성 시 말머리에 태그를 붙여주세요.

Tag	의미	Action	설명
P1	꼭 반영해주세요	Request changes	서비스에 중대한 오류를 발생시킬 가능성이 있거나 반드시 수정이 필요한 경우입니다. 작성자는 반드시 반영하거나, 합당한 이유로 리뷰어를 설득해야 합니다.
P2	적극적으로 고려해주세요	Request changes	수용을 권장하며, 수용할 수 없는 경우 적합한 의견을 들어 토론할 것을 권장합니다.
P3	웬만하면 반영해 주세요	Comment	수용하거나, 반영할 수 없다면 이유나 추후 계획(Jira 티켓 등)을 명시하는 것을 권장합니다.
P4	반영해도 좋고 넘어가도 좋습니다	Approve	작성자가 무시해도 괜찮습니다. 해당 의견을 반영하는 게 좋을지 고민해 보는 정도면 충분합니다.
P5	그냥 사소한 의견입니다	Approve	작성자가 아무런 의견을 달지 않고 무시해도 괜찮습니다.