이 문서는 프로젝트의 일관된 코드 관리와 효율적인 협업을 위한 Git 운영 전략을 정의합니다.

1. 브랜치 전략: main / dev / feature

우리 프로젝트는 main / dev / feature 브랜치 전략을 사용하여

안정적인 배포와 효율적인 협업을 목표로 합니다.

• main 브랜치
  • 실제 제품이 배포되는 기준 브랜치입니다.
  • 항상 배포 가능한 안정 상태를 유지해야 합니다.
  • dev 브랜치에서 충분히 검증된 코드만 병합됩니다.
• dev 브랜치
  • 기능 개발이 완료된 브랜치들이 통합되는 개발 브랜치입니다.
  • 여러 feature 브랜치를 병합하여 테스트 및 검증을 진행합니다.
  • 배포 준비가 완료되면 main 브랜치로 병합됩니다.
• feature 브랜치
  • 새로운 기능 개발, 버그 수정 등 개별 작업 단위 브랜치입니다.
  • dev 브랜치에서 분기하여 작업합니다.
  • 작업 완료 후 PR을 통해 dev 브랜치로 병합합니다.
  • 명명 규칙: type/#number
    • 예시: feat/#1, fix/#22

2. 작업 프로세스 (Workflow)

1. Issue 생성: 작업 시작 전 Issue를 발행하여 작업 내용을 정의합니다.
2. Branch 생성: main 브랜치에서 최신 코드를 pull 받은 후, 새로운 feature 브랜치를 생성합니다.
3. Commit & Push: 작업 단위별로 커밋 메시지 규칙을 지켜 커밋하고, 원격 저장소에 push합니다.
4. Pull Request (PR) 생성: 작업이 완료되면 main 브랜치로 PR을 보냅니다.
5. Review & Merge: 팀원의 리뷰와 승인을 받은 후 main 브랜치에 Merge합니다. (머지 후 브랜치는 삭제합니다.)

3. 커밋 메시지 컨벤션 (Commit Message Convention)

커밋 메시지는 제목(Subject)만으로도 변경 내용을 알 수 있도록 아래 형식을 따릅니다.

• 형식: type: Description
• 주요 타입(Type):
  • feat: 새로운 기능 추가
  • fix: 버그 수정
  • docs: 문서 수정 (README, 위키 등)
  • style: 코드 의미에 영향을 주지 않는 변경 (세미콜론, 포맷팅 등)
  • refactor: 코드 리팩토링
  • test: 테스트 코드 추가 및 수정
  • chore: 빌드 업무, 패키지 매니저 설정 등 기타 작업

4. Pull Request (PR) 규칙

• 제목: [Type] 작업 요약 (예: [Feat] 카카오 로그인 기능 구현)
• 내용 필수 포함 항목:
  • 변경 사항에 대한 간략한 설명
  • 관련 Issue 번호 (#이슈번호)
  • 테스트 통과 여부 및 스크린샷 (UI 변경 시)