Git Flow 브랜치 전략 (Git Flow Branching Model)

Git Flow는 대규모 프로젝트나 정기적인 배포 주기를 가진 소프트웨어 개발 프로세스를 위한 표준적인 브랜칭 전략이다. 코드의 안정성을 높이고 개발자 간의 충돌을 최소화하며 협업을 원활하게 만들어 준다.

Git Flow는 프로젝트 전체 기간 동안 항상 유지되는 2개의 메인 브랜치와, 특정 목적을 위해 필요할 때 생성되고 삭제되는 3개의 보조 브랜치로 구성된다.

---

1. 메인 브랜치

프로젝트의 시작부터 끝까지 항상 유지되는 핵심 브랜치이다.

🟢 main

• 역할: 실제 사용자에게 배포되는 가장 안정적인 코드가 있는 브랜치이다.
• 특징: 이 브랜치의 모든 코드는 언제든 배포가 가능한 상태여야 한다. 배포가 일어날 때마다 해당 시점에 버전 태그(Tag, 예: v1.0.0)를 추가하여 배포 이력을 관리한다.

🔵 develop

• 역할: 다음 출시에 배포할 새로운 기능들이 모이는 개발 중심 브랜치이다.
• 특징: main 브랜치에서 분기되어 생성되며, 개발자들은 이 브랜치를 기준으로 기능 개발(feature)을 시작한다. 모든 개발 작업의 뼈대가 되며 코드가 통합되고 테스트되는 공간이다.

---

2. 보조 브랜치

기능 개발, 배포 준비, 버그 수정 등 특정 목적을 위해 일시적으로 생성되며, 목적을 달성하면 메인 브랜치에 병합된 후 깔끔하게 삭제된다.

🚀 feature (기능 브랜치)

• 목적: 새로운 기능 개발이나 기존 기능의 개선을 진행할 때 사용한다.
• 흐름: develop 브랜치에서 분기하고, 작업이 완료되면 다시 develop으로 병합(Merge)된다.
• 명명 규칙: 주로 feature/기능명 또는 feature/이슈번호 형태로 작성한다.

  예: feature/login, feature/user-profile, feature/#123

• 특징: 개발자 개인의 로컬 저장소에서 주로 작업하며, 완료 후 원격 저장소에 올려 Pull Request(PR)를 통해 코드 리뷰를 거친 후 병합하는 것이 일반적이다.

📦 release (배포 준비 브랜치)

• 목적: 새로운 버전을 실제 배포하기 전, 품질 검사(QA)를 진행하고 자잘한 버그를 수정하며, 버전 번호 등 메타데이터 설정을 진행하는 브랜치이다.
• 흐름: 이번 배포에 포함될 기능들이 develop 브랜치에 모두 모이면 분기한다. 배포 준비가 완벽히 끝나면 main에 병합된다.
• 명명 규칙: release/버전명 형태로 작성한다.

  예: release/v1.2.0

• 특징: release 브랜치가 생성된 이후에는 새로운 대규모 기능을 추가할 수 없으며, 오직 배포를 위한 안정화 작업만 이루어진다. main에 병합할 때는 반드시 해당 버전의 태그를 생성해야 한다.

🚨 hotfix (긴급 수정 브랜치)

• 목적: 이미 사용자에게 배포된 main 환경에서 치명적인 버그(예: 서버 다운, 결제 오류 등)가 발견되었을 때 긴급하게 수정하기 위해 사용한다.
• 흐름: 문제가 발생한 main 브랜치의 특정 태그에서 직접 분기한다. 수정이 완료되면 main과 develop 양쪽 모두에 병합된다.
• 명명 규칙: hotfix/버전명 형태로 작성한다.

  예: hotfix/v1.2.1

• 특징: 다음 정기 배포를 기다릴 여유가 없으므로 develop이 아닌 main에서 직접 파생된다. 수정한 내역이 이후 개발 버전에 누락되어 똑같은 버그가 재발하지 않도록 develop에도 반드시 병합해 주어야 한다.

---

💡 한눈에 보는 Git Flow 작업 흐름 (Workflow)

1. 초기 설정: 프로젝트 시작 시 main 브랜치에서 develop 브랜치를 생성한다.
2. 기능 개발: 개발자는 develop에서 새로운 feature 브랜치를 따와서 작업을 진행한다.
3. 기능 통합: 개발이 끝나면 feature 브랜치를 develop에 병합하고, 작업했던 feature 브랜치는 삭제한다.
4. 배포 준비: 배포할 기능들이 develop에 충분히 모이면, release 브랜치를 생성하여 QA 및 최종 테스트를 진행한다.
5. 배포 완료: 테스트가 성공적으로 끝나면 release 브랜치를 main과 develop에 병합하고, main에는 릴리즈 버전 태그를 붙인다.
6. 긴급 수정(필요시): 운영 환경(Production)에서 심각한 오류가 발생하면 main에서 hotfix 브랜치를 생성해 신속히 수정하고, 완료되면 main과 develop에 병합 후 패치 버전 태그를 업데이트한다.