# [[Git Flow]]

## 📌 Brief Summary
Git Flow는 주로 정기적인 릴리스(scheduled releases) 일정이 있는 대규모 프로젝트에 유용한 소프트웨어 개발 브랜칭 전략입니다. 이 워크플로우는 코드를 안전하게 통합하고 배포하기 위해 `main` 브랜치 외에 `develop`, `release` 등 명확한 목적을 가진 여러 브랜치를 구조적으로 분리하여 사용합니다. 그러나 복잡도가 높기 때문에 소규모 팀이나 빠른 통합이 필요한 환경에서는 오버헤드가 발생할 수 있습니다.

## 📖 Core Content
*   **Git Flow의 핵심 구조:** Git Flow는 `main` 브랜치 외에 새로운 통합(integration) 브랜치인 `develop` 브랜치를 생성하여 사용합니다. 새로운 기능(Feature)을 개발할 때는 이 `develop` 브랜치를 기반으로 작업하며, 기능 개발이 완료되면 다시 `develop` 브랜치에 병합(Merge)합니다 [1].
*   **릴리스 관리:** 배포 준비를 위해 별도의 `release` 브랜치를 추가로 사용합니다 [1, 2]. 이를 통해 대규모 프로젝트에서 정해진 일정에 따른 릴리스를 체계적으로 관리하고, 최종 테스트 및 배포 준비 과정을 다른 기능 개발과 격리할 수 있습니다 [1, 3].
*   **다른 브랜칭 전략과의 비교 및 마이그레이션:** Git Flow는 GitHub Flow, GitLab Flow, Trunk-Based Development, Feature Branch Workflow 등과 함께 널리 쓰이는 주요 브랜칭 전략 중 하나입니다 [4]. 팀의 요구사항이 변함에 따라 다른 전략으로 마이그레이션이 가능합니다. 예를 들어 더 단순한 관리가 필요하면 릴리스 브랜치를 없애고 `develop`을 `main`에 통합하여 GitHub Flow로 넘어가거나, 반대로 체계적인 구조가 필요할 경우 `develop`과 `release` 브랜치를 추가하여 Git Flow로 전환할 수 있습니다 [1, 2].
*   **모범 사례의 적용:** Git Flow를 사용할 때도 보편적인 Git 워크플로우 모범 사례(Best Practices)를 따라야 합니다. 의미 있는 짧은 브랜치명 사용, 티켓 ID(예: PROJ-123) 포함, Pull Request(PR)를 통한 코드 리뷰, 그리고 브랜치 병합 후 삭제 등을 철저히 지켜야 합니다 [5-8].

## ⚖️ Trade-offs & Caveats
*   **오버헤드와 복잡성:** Git Flow는 관리해야 할 브랜치의 종류가 많고 규칙이 엄격하여 프로세스 오버헤드를 발생시킵니다 [9, 10]. 2~5명 규모의 소규모 팀이나 초보자에게는 너무 무거운(heavy) 전략이며, 오히려 개발 속도를 늦출 수 있습니다 [3, 11, 12].
*   **통합 속도 및 충돌 문제:** 여러 브랜치 계층(`feature` -> `develop` -> `release` -> `main`)을 거쳐야 하므로 코드 병합과 배포 속도가 Trunk-Based Development나 단순한 Feature Branch 워크플로우에 비해 느려집니다 [2, 3]. 수명이 긴 브랜치가 발생할 확률이 높아 큰 머지 충돌(Merge Conflict)을 겪을 위험이 있습니다 [10, 13].

## 🔗 Knowledge Connections

### Related Concepts

#### [관계 유형 A (아키텍처/기반 전략)]
- [[GitHub Flow]]
  - 연결 이유: Git Flow보다 더 단순한 대안으로 자주 비교되며, Git Flow에서 릴리스 브랜치와 `develop` 브랜치를 제거하여 `main`으로 직접 병합하는 형태로 마이그레이션할 수 있습니다 [2].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 브랜칭 전략의 복잡도를 낮추고 배포 주기를 단축하여 보다 민첩한 개발을 수행하는 방법.
- [[Trunk-Based Development]]
  - 연결 이유: 강력한 CI와 짧은 수명의 브랜치를 활용하여 매우 빠른 통합을 추구하는 전략으로, 복잡하고 무거운 Git Flow와 극명하게 대비됩니다 [2, 3].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 브랜치 계층을 최소화하여 통합 충돌을 줄이고, 빠른 주기로 코드를 배포하는 방식.
- [[Feature Branch Workflow]]
  - 연결 이유: 모든 변경 사항을 `main`이 아닌 특정 기능(Feature)을 위한 전용 브랜치에서 작업하는 방식으로, Git Flow를 포함한 대부분의 브랜칭 전략의 기반이 되는 핵심 개념입니다 [5, 12, 14].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 논리적 단위로 코드를 격리하고 충돌을 방지하며 작업 내역을 명확히 하는 원리.

#### [관계 유형 B (구현/거버넌스 도구)]
- [[Pull Request (PR)]]
  - 연결 이유: Git Flow의 복잡한 브랜치 환경(예: feature에서 develop으로 병합)에서 코드를 병합하기 전에 동료 리뷰를 거치게 하는 필수적인 품질 통제 관문입니다 [7, 15].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 팀 내 코드 품질 유지, 지식 공유 및 병합 전 결함 차단 메커니즘.
- [[Conventional Commits]]
  - 연결 이유: 수많은 브랜치와 커밋이 얽히는 Git Flow에서 커밋 메시지를 규격화(`feat:`, `fix:`, `chore:` 등)하여 기록을 명확히 하고 릴리스 관리를 용이하게 합니다 [15, 16].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 대규모 프로젝트에서 코드 변경 이력을 일관되게 추적하고 관리하는 규약.

### Deeper Research Questions

- Git Flow의 `develop` 브랜치와 `main` 브랜치를 장기간 분리하여 운영할 때 필연적으로 발생하는 머지 충돌(Merge Conflict)을 최소화하기 위한 구체적인 동기화 전략은 무엇인가?
- 소규모 팀이 단일 브랜치 또는 단순 Feature Branch Workflow에서 Git Flow로 전환(Migration)해야 하는 가장 적절한 조직적, 비즈니스적 타이밍과 기준은 무엇인가?
- Git Flow 환경에서 긴급한 운영 서버 버그 수정(Hotfix)이 발생했을 때, `main`과 `develop` 브랜치 양쪽에 안전하고 신속하게 반영하기 위한 절차는 어떻게 구성되는가?
- Git Flow와 Trunk-Based Development의 브랜치 수명(Lifetime) 차이가 CI/CD 파이프라인의 구축 및 자동화 테스트 횟수에 구체적으로 어떤 영향을 미치는가?
- 추적성을 위해 티켓 ID(예: JIRA)를 브랜치와 커밋에 사용할 때, 복잡한 릴리스 브랜치(Release Branch) 단계에서 여러 티켓의 변경 사항 누락을 방지하는 모범 관행은 무엇인가?

### Practical Application Contexts

- **Implementation:** 대규모 프로젝트에서 `main` 브랜치는 항상 안정적이고 배포 가능한 상태로 보호하며, 실질적인 개발 통합은 `develop` 브랜치를 생성하여 관리합니다 [1, 12]. 모든 커밋과 브랜치명에는 티켓 ID를 포함시켜 요구사항과의 추적성을 확보합니다 [7].
- **System Design:** 예약된 릴리스 스케줄을 지원하는 소프트웨어 아키텍처에 적합하며, 배포 전에 `release` 브랜치를 통해 최종 QA와 버전 태깅(Tagging)을 수행할 수 있도록 파이프라인을 설계합니다 [1, 3, 7].
- **Operation / Maintenance:** 브랜치 보호(Branch Protection), 리뷰어 필수 지정, CI 상태 체크 기능을 활용하여 `develop` 브랜치의 코드 품질을 보장하며, 머지 후에는 작업이 끝난 브랜치를 자동 삭제하여 리포지토리를 깔끔하게 유지합니다 [5, 13].
- **Learning Path:** 처음부터 Git Flow를 도입하기보다는, 가벼운 Feature Branch Workflow 또는 GitHub Flow로 기본기를 다진 후, 릴리스 관리의 복잡성이 증가함에 따라 점진적으로 `develop`과 `release` 브랜치 개념을 학습하고 도입하는 것이 권장됩니다 [1-3].
- **My Project Relevance:** 현재 진행 중인 프로젝트의 팀 규모와 배포 주기에 따라 채택 여부를 결정해야 합니다. 팀원이 3~5명인 소규모 환경이라면 오버헤드가 큰 Git Flow보다는 짧은 수명의 Feature 브랜치와 결합된 더 단순한 워크플로우가 유리합니다 [3, 10, 14].

### Adjacent Topics

- [[CI/CD (Continuous Integration/Continuous Deployment)]]
  - 확장 방향: Git Flow의 여러 브랜치(`develop`, `release`, `main`) 환경에 맞춰 단계별로 자동화된 테스트 및 배포 파이프라인을 어떻게 다르게 구축하는지 탐구.
- [[Agile Methodology]]
  - 확장 방향: Git Flow의 릴리스 브랜치 운용이 애자일의 스프린트(Sprint) 주기 및 이슈 트래커(Issue Tracker)와 어떻게 통합되어 소프트웨어 릴리스 프로세스를 형성하는지 분석.

---
*Last updated: 2026-04-30*