Branch strategy

협업 브랜치 전략

Branch 관리는 git flow방식을 사용합니다.

• 본 브랜치는 main 이며 모든 병합은 PR을 통해서만 진행합니다.
• main 브랜치는 앱스토어 배포가 진행된 경우에만 병합하고 해당 버전에 일치하는 태그를 생성하여 저장소에 push합니다.

1. 피처를 시작하는 경우

• develop 브랜치에서 feature/{feature 이름} 브랜치를 생성한 후 원격 저장소에 push합니다.

2. 피처에서 작업을 하는 경우

• feature/{feature 이름} 브랜치에서 자기 자신에게 할당된 이슈 브랜치를 생성합니다.
• 여기서 브랜치 이름은 #{Issue number}-{Issue name} 형태로 생성합니다. ex.) #1-fix-throttle
  • Issue number는 Github Issues에 정의된 이슈 코드를 의미합니다. ex.) #1
• 티켓 작업이 완료되면 feature/{feature 이름} 타겟 브랜치로 PR을 생성합니다. PR이 승인되면 feature/{feature 이름} 로 머지됩니다.
• 하나의 피처에서 2명 이상의 개발자가 작업을 진행해도 피처 브랜치를 베이스로 각자 티켓별 브랜치를 생성하므로 머지 시, 충돌 발생 확률이 적습니다.

3. 피처 작업이 완료된 경우

• feature/{feature 이름} 브랜치에 모든 티켓이 완료되어 작업 사항이 모두 반영되어있는 상태에서 Develop브랜치로 머지를 합니다.
• 하나의 버전 업데이트에 여러개의 피처가 들어간다면 각각의 피처가 피처 브랜치에서 진행되다가 develop브랜치로 모입니다.

4. QA배포 시작 및 QA 이슈 수정하는 경우

• QA 배포를 시작하는 경우 develop브랜치에서 release/{버전 이름} 브랜치를 생성한 후, 원격 저장소에 push합니다.
• QA 이슈가 발생하면 해당 이슈들은 깃허브 이슈로 만들어집니다. 그럼 release/{버전 이름} 브랜치에서 이슈 코드로 브랜치를 생성하여 작업합니다.
• 이슈별로 QA 이슈 수정이 완료되면 release/{버전 이름} 브랜치로 PR을 생성합니다. 즉, QA 이슈들은 release/{버전 이름} 브랜치에서 수정됩니다.
• QA 이슈가 모두 수정되면 release/{버전 이름} 브랜치에서 다시 빌드하여 배포합니다.
• QA가 n차까지 이어진다면 위 과정을 반복합니다.
• 모든 QA가 끝나면 **release/{버전 이름}**브랜치에서 앱 심사를 요청합니다.

5. QA가 끝나고 앱이 릴리즈된 경우

• 앱 심사가 완료되고 릴리즈까지 모두 진행했다면 release/{버전 이름} 브랜치를 develop, master 브랜치에 각각 머지시킵니다.
• main브랜치에 머지가 완료되면 해당 커밋에 버전 이름 (v5.1.2)로 태그를 생성합니다.
  • 태그는 버전별 커밋 위치를 기억하기 위함입니다.

6. 핫픽스 진행하는 경우

• main 브랜치에서 hotfix/{버전 이름} 으로 핫픽스 브랜치를 생성한 후 원격 저장소에 push 합니다.
• 핫픽스 이슈 수정도 피처, QA이슈 수정과 동일하게 hotfix/{버전 이름} 브랜치에서 지라 티켓 코드로 된 브랜치를 생성한 후 작업합니다.
• 모든 이슈가 수정되었다면 hotfix브랜치에서 심사요청을 진행하고 심사가 승인되어 앱이 배포된 경우에 main브랜치와 develop브랜치로 바로 머지합니다.