Git Flow 전략

브랜치 구조

각 브랜치는 Base가 되는 브랜치에 맞춰 계층 구조를 나타낸다.

• master: 배포 브랜치. 문제가 없는 안정된 브랜치

  • develop: 주차별 작업이 완료된 후 테스트를 거치는 브랜치

    • weekly/{주차}: 각 주차별 할당된 작업을 수행하는 브랜치 (예: weekly/3)

      • feature/{이슈번호}-{기능명}: 특정 기능을 개발하기 위한 브랜치 (예: feature/3-login)

  • review: 리뷰 브랜치. 리뷰가 필요할 때, 이 브랜치로 PR 요청

작업 시작 전 (Admin 역할)

매 주차마다 weekly/{주차} 브랜치를 생성한다.

팀원 작업 시나리오

1. weekly 브랜치 pull 또는 fetch& rebase 수행한다.

2. weekly/{주차} 브랜치를 Base로 하여 feature/{기능명} 브랜치를 생성한다.

3. feature/{이슈번호}-{기능명} 브랜치에서 커밋 컨벤션을 참고하여 작업을 진행한다.

4. 작업 완료 후, weekly/{주차} 브랜치로 PR 요청한다.

5. 한 명 이상의 팀원이 PR을 Approve해야만 Merge가 가능하다.

6. Approve 받은 후, Admin이 PR을 Merge할 때까지 기다린다.

해당 주차의 Task가 끝날 때까지 위 과정을 반복한다.

작업 완료 후 (Admin 역할)

1. Admin이 weekly/{주차} 브랜치를 develop 브랜치에 PR & Merge한다.

2. Admin이 develop 브랜치를 master 브랜치에 PR & Merge한다.

3. 리뷰가 필요한 주차에는, master 브랜치에서 review 브랜치로 PR 요청한다.

작업 완료 후 (팀원 역할)

로컬에 있는 브랜치와 깃허브에 있는 브랜치 버전 차이 없애기 (=동기화 하기)