협업 규칙 (Ji-kku)

이 문서는 frontend / backend 두 레포에 동일하게 넣어두세요.

개발 흐름 한눈에 보기

이슈 → 브랜치 → 개발 → PR → 리뷰 → 머지

1. 이슈 먼저 만들기 — 모든 작업은 이슈 생성으로 시작합니다.
2. 이슈에서 브랜치를 따서 개발합니다.
3. 작업이 끝나면 PR을 올리고, 해당 이슈를 연결합니다.
4. 리뷰어 1명 승인 후 머지합니다.

이슈 규칙

• 개발을 시작하기 전에 먼저 이슈를 만듭니다. (기능·버그·문서 등 모든 작업)
• 이슈에는 무엇을, 왜 하는지 간단히 적습니다. 필요하면 체크리스트로 할 일을 나눕니다.
• 이슈 제목도 커밋처럼 종류: 내용 형식을 권장합니다. (예: [FEATURE] 지역별 축제 목록 API)
• 만들어진 이슈 번호(#12 등)를 브랜치·PR에서 참조합니다.

브랜치 전략 — GitHub Flow

• main 은 항상 동작하는 상태로 유지합니다. 직접 push 하지 않고 PR로만 머지합니다.
• 모든 작업은 이슈에서 출발해 main 에서 새 브랜치를 따서 진행합니다.
• 머지가 끝난 브랜치는 삭제합니다.

브랜치 이름: 종류/내용

종류	용도
feat	새 기능
fix	버그 수정
refactor	리팩터링
docs	문서
chore	설정·잡일

• 내용엔 이슈 번호만 무조건 붙입니다. 예: feat/#12 (이슈 #12)

커밋 메시지: 종류: 내용

• feat: 새 기능
• fix: 버그 수정
• docs: 문서
• style: 포맷·세미콜론 등 (동작 변화 없음)
• refactor: 리팩터링
• test: 테스트
• chore: 빌드·설정

예시: feat: 시·군 클릭 시 세부지도로 이동

PR 흐름

1. 이슈를 먼저 만들었는지 확인합니다. (이슈 없는 PR은 지양합니다.)
2. 작업 시작 전 main 을 최신으로 당겨옵니다. (git pull origin main)
3. 이슈에서 브랜치를 따서 개발합니다.
4. 큰 덩어리 대신 작은 단위로 자주 PR을 올립니다.
5. PR 템플릿을 채우고, 본문에 Closes #12 처럼 이슈를 연결합니다.
   • Closes/Fixes/Resolves 를 쓰면 머지 시 이슈가 자동으로 닫힙니다.
6. 리뷰어 1명 승인 후 머지합니다.
7. 머지 후 작업 브랜치를 삭제합니다. (이슈는 자동으로 닫힙니다.)

꼭 지킬 것

• .env 등 비밀값(TourAPI 키, JWT 시크릿, 스토리지 키)은 절대 커밋하지 않습니다.
• 공유가 필요하면 .env.example 에 변수 이름만 적습니다(값은 비워둠).
• 작업 전 항상 main 최신화 → 충돌을 작게 유지합니다.