<aside> 💡

모든 Server 팀원들은 아래 컨벤션 가이드를 상세히 읽고 반드시 준수해 주세요.

</aside>

1. 반드시 지켜야 할 규칙

• 커밋 메시지는 컨벤션에 따라 간결하고 직관적으로 작성합니다.
• 이미 공유된 원격 브랜치의 히스토리를 임의로 수정(force push 등)하지 않습니다.
• PR를 main 브랜치에 머지하기 전, 최소 1명 이상의 팀원에게 반드시 Approve 받아야 합니다.
• 리뷰가 완료된 PR은 작성자 본인이 직접 충돌을 해결하고 머지합니다.

각 브랜치의 수명은 최대한 짧게 유지합니다.

브랜치의 수명이 길어질수록 main 브랜치와의 격차가 벌어져, Rebase 과정에서 Conflict가 발생할 확률이 높아집니다. 기능은 가능한 한 작게 쪼개어 빠르게 머지하세요.

2. 워크플로우

모든 작업은 GitHub Issue 생성으로 시작하며, 아래의 순서에 따라 진행합니다.

1. GitHub 이슈를 생성합니다.
   • 형식: [FEATURE/FIX] 이슈 내용
   • ex) [FEATURE] 구글 소셜 로그인 구현
   • ex) *[FIX] 게시판 API 응답 형식 수정*
2. main 브랜치에서 분기하는 새 브랜치를 생성합니다. 이슈 번호를 브랜치명에 포함합니다.
   • 형식: feature/#{이슈번호}-작업내용
   • ex) feature/#12-google-login
   • ex) fix/#13-board-api-response-format
3. 분기한 브랜치에서 작업을 진행합니다.
4. 구현된 단위별로 커밋을 남깁니다. (커밋 컨벤션 준수)
5. (선택) 히스토리를 깔끔하고 간결하게 유지하기 위해 필요한 경우 커밋을 Squash로 하나로 합칩니다.
6. 최신 원격 코드를 가져옵니다. (git fetch origin)
7. 최신 main 브랜치 위로 내 작업 브랜치를 Rebase하고, 발생하는 충돌을 해결합니다.
8. Rebase가 완료된 브랜치를 원격 저장소에 푸시합니다. (git push)
9. Pull Request를 생성합니다.
10. 리뷰어의 피드백을 반영하고 최종 승인을 받습니다.