Team Collaboration Rule
우리 팀의 개발 프로세스와 협업 규칙을 정의합니다. 모든 팀원은 원활한 협업과 코드 품질 유지를 위해 아래 규칙을 준수합니다.
우리는 GitHub Flow를 기반으로 브랜치를 운용합니다.
-
master: 제품으로 배포되는 메인 브랜치입니다. (Direct Push 금지) -
feature/*: 새로운 기능을 개발하는 브랜치입니다. -
hotfix/*: 배포 후 발생한 긴급 버그를 수정하는 브랜치입니다.
모든 브랜치 이름에는 트래킹을 위해 Jira Issue Key를 반드시 포함합니다.
feature/[Jira-Key]-[Description]hotfix/[Jira-Key]-[Description]
Ex)
feature/PROJ-101-login-page
이슈 트래킹과 코드 변경 사항의 연결을 위해 엄격한 컨벤션을 따릅니다.
커밋 메시지 헤더에 이슈 키를 포함하여 Jira 티켓과 연동되도록 합니다.
[Type]-[Jira-Key]: [Description]
Ex)
feat-PROJ-101: 로그인 페이지 레이아웃 구현Ex)fix-PROJ-102: 로그인 버튼 비활성화 오류 수정
- Traceability: 커밋 메시지, PR 제목, 브랜치 이름 등 모든 곳에 Jira Issue Key를 명시합니다.
- Status Management: Jira 티켓의 상태 변경(To Do → In Progress → Done)은 작업자가 수동으로 최신화합니다.
- 1 PR 1 Feature: 하나의 PR은 하나의 기능 단위로 작성하는 것을 원칙으로 합니다.
- No File Limit: 파일 변경 개수에 제한은 없으나, 리뷰 효율을 고려하여 작성합니다.
PR 작성 시 아래 템플릿 양식을 준수합니다.
🚩 What is this PR?
📢 Changes-Detail
📃 Progress Completed:
To-do:
✅ Checklist
[ ] Jira issue key is included
📸 Screenshots or Video
⚙️ Additional Notes
코드 품질 유지와 안정성을 위해 강도 높은 리뷰 프로세스를 거칩니다.
- Direct Push 금지: 모든 변경사항은 PR을 통해서만 병합됩니다.
- CI Build Check: CI 빌드가 성공해야만 병합(Merge)이 가능합니다.
- Review Requirement: 최소 **2명 이상의 리뷰어 승인(Approve)**이 있어야 병합이 가능합니다.
리뷰어(Pool: 3명)는 다음 사항을 중점적으로 검토합니다.
- MVC Pattern: 아키텍처 패턴을 올바르게 준수했는가?
- Consistency: 기존 코드 스타일 및 구조와 일관성이 있는가?
- Reusability: 코드의 재사용성을 고려하여 작성되었는가?
리뷰어의 의도를 명확히 전달하기 위해 **Pn 룰(Priority Rule)**을 사용합니다. 코멘트 작성 시 말머리에 태그를 붙여주세요.
| Tag | 의미 | Action | 설명 |
|---|---|---|---|
| P1 | 꼭 반영해주세요 | Request changes |
서비스에 중대한 오류를 발생시킬 가능성이 있거나 반드시 수정이 필요한 경우입니다. 작성자는 반드시 반영하거나, 합당한 이유로 리뷰어를 설득해야 합니다. |
| P2 | 적극적으로 고려해주세요 | Request changes |
수용을 권장하며, 수용할 수 없는 경우 적합한 의견을 들어 토론할 것을 권장합니다. |
| P3 | 웬만하면 반영해 주세요 | Comment |
수용하거나, 반영할 수 없다면 이유나 추후 계획(Jira 티켓 등)을 명시하는 것을 권장합니다. |
| P4 | 반영해도 좋고 넘어가도 좋습니다 |
Approve |
작성자가 무시해도 괜찮습니다. 해당 의견을 반영하는 게 좋을지 고민해 보는 정도면 충분합니다. |
| P5 | 그냥 사소한 의견입니다 | Approve |
작성자가 아무런 의견을 달지 않고 무시해도 괜찮습니다. |