# [[Branching Strategies|Branching Strategies]]

## 📌 Brief 소Summary
Branching Strategies(브랜칭 전략)는 소프트웨어 개발 과정에서 코드 변경 사항을 관리하고 팀원 간의 협업을 조율하기 위해 버전 관리 시스템(Git 등)에서 브랜치를 생성, 병합, 유지보수하는 규칙과 워크플로우를 의미합니다. 팀의 규모와 프로젝트 요구사항에 따라 Git Flow, GitHub Flow, Trunk-Based Development, Feature Branch Workflow 등 다양한 전략이 사용됩니다. 명확한 브랜칭 전략의 도입은 메인 코드베이스의 안정성을 보장하고 병합 충돌을 방지하며 코드 리뷰와 추적성을 강화하는 핵심 역할을 합니다 [1-3].

## 📖 Core Content
*   **주요 브랜칭 전략 유형**
    *   **Feature Branch Workflow (기능 브랜치 워크플로우):** 2~5명 규모의 소규모 팀에 가장 초보자 친화적이고 충돌이 적은 워크플로우입니다 [4]. `main` 브랜치는 항상 안정적이고 배포 가능한 상태를 유지하며, 새로운 기능이나 버그 수정 시 `main`에서 파생된 짧은 수명의 브랜치를 생성합니다 [5]. 개발 완료 후 Pull Request(PR)를 열고 최소 1명 이상의 동료 리뷰와 테스트를 거친 후 Squash Merge 방식으로 병합합니다 [6, 7].
    *   **Trunk-Based Development (트렁크 기반 개발):** 강력한 CI(지속적 통합) 환경을 갖춘 숙련된 팀에 적합한 가벼운 방식입니다 [8, 9]. 수명이 매우 짧은 기능 브랜치를 사용하거나 메인 브랜치에 작은 변경 사항을 자주 커밋합니다. 오버헤드가 최소화되고 피드백이 빠르며 대규모 병합 충돌을 피할 수 있습니다 [8, 10].
    *   **Git Flow:** 정기적인 릴리스 일정을 가진 대규모 프로젝트에 유용합니다 [9]. 하지만 기능 브랜치 외에도 `develop`, `release` 등 관리해야 할 브랜치가 많아 소규모 팀에게는 무겁고 과도한 복잡성을 유발할 수 있습니다 [9, 11, 12].
    *   **GitHub Flow:** `main` 브랜치로 기능 브랜치를 직접 병합하는 단순화된 구조로, Git Flow보다 빠르고 지속적인 배포 환경에 적합합니다 [11, 13].

*   **모든 전략에 적용되는 모범 사례 (Best Practices)**
    *   **티켓 ID 및 명명 규칙 사용:** 브랜치 이름과 커밋 메시지에 요구사항 추적을 위한 티켓 ID(예: `feature/PROJ-123-user-auth`)를 포함해야 합니다 [14, 15]. 브랜치 이름은 케밥 케이스(kebab-case)를 사용하고 짧고 명확하게 작성합니다 [16, 17].
    *   **원자적 커밋 (Atomic Commits):** 하나의 커밋에는 하나의 논리적 변경 사항만 포함하여 코드 리뷰와 히스토리 추적을 단순화합니다 [7, 18].
    *   **Conventional Commits 규칙:** 커밋 메시지는 `feat:`, `fix:`, `chore:` 등의 표준화된 접두사를 사용하여 변경의 목적을 명확히 합니다 [19-21].
    *   **PR 및 병합 규칙:** 코드를 절대 `main`에 직접 푸시해서는 안 되며, 반드시 PR을 통한 리뷰를 거쳐야 합니다 [6, 22]. 병합 후에는 사용이 끝난 브랜치를 즉시 삭제하여 저장소를 정리합니다 [6, 23].

*   **전략 간 마이그레이션 방법**
    *   프로젝트가 변화함에 따라 전략도 진화할 수 있습니다. 예를 들어 통합 속도를 높이려면 Feature Branch에서 Trunk-Based(기능 플래그 사용 및 수명 단축)로 전환하고, 더 많은 체계가 필요하다면 GitHub Flow에서 Git Flow(`develop` 브랜치 및 릴리스 브랜치 추가)로 마이그레이션할 수 있습니다 [11, 12].

## ⚖️ Trade-offs & Caveats
*   **구조적 오버헤드 vs. 안정성:** Git Flow는 구조가 명확하고 정기적인 릴리스에 강점이 있지만, 브랜치의 수가 많아 유지보수 비용(오버헤드)이 높습니다 [9]. 반면 Feature Branch나 Trunk-Based 방식은 프로세스가 가벼운 대신 메인 브랜치의 보호(`main` 브랜치 직접 푸시 금지, 엄격한 코드 리뷰 등) 규칙이 강제되지 않으면 코드가 쉽게 깨질 위험이 있습니다 [6, 22].
*   **기능 브랜치의 수명(Long-lived branches) 문제:** 기능 브랜치나 GitHub Flow를 사용할 때, 브랜치의 수명이 몇 주 이상 길어지면 다른 작업자와의 코드 분기가 심해져 거대한 병합 충돌(Merge conflicts)이 발생할 수 있습니다 [17]. 따라서 매일 `main`의 최신 변경 사항을 Pull 하거나 Rebase하여 충돌을 예방해야 합니다 [7].
*   **Trunk-Based 개발의 의존성:** 빠른 병합을 지향하는 Trunk-Based Development는 지속적이고 자동화된 테스트 환경(CI)과 미완성 기능을 프로덕션에서 숨기기 위한 기능 플래그(Feature Flags) 구현 등 기술적 뒷받침이 필수적입니다 [9, 11].

## 🔗 Knowledge Connections

### Related Concepts

#### [관계 유형 A: 아키텍처/기반 방법론]
- Feature Branch Workflow
  - 연결 이유: 소규모 3~5인 개발 팀에 가장 추천되는 단순하고 직관적인 브랜칭 전략의 기반 개념입니다.
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 메인 브랜치를 오염시키지 않고 새로운 기능을 격리된 환경에서 개발하고 병합하는 방법론을 이해할 수 있습니다.
- Trunk-Based Development
  - 연결 이유: 무거운 워크플로우를 탈피하여 브랜치 생명주기를 극한으로 줄이고 빠른 통합을 중시하는 최신 트렌드 모델입니다.
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: CI/CD 환경에서의 잦은 소규모 배포 방식과 충돌 최소화 전략을 학습할 수 있습니다.
- Git Flow
  - 연결 이유: 브랜칭 전략의 고전적이고 체계적인 형태로서, 대형 프로젝트의 정기적 버저닝 관리를 위해 설계되었습니다.
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: `develop`, `release`, `hotfix` 등 개발 파이프라인에 따른 브랜치의 역할 분리 기법을 이해할 수 있습니다.

#### [관계 유형 B: 구현/활용 도구 및 규칙]
- Pull Request & Code Review
  - 연결 이유: 브랜칭 전략이 안전하게 동작하기 위해 모든 병합 전에 필수적으로 거쳐야 하는 품질 검증 관문입니다.
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 팀원 간의 비동기적 피드백 수렴, 시각적 검증, 그리고 CI 통과를 전제로 한 안전한 병합 과정을 배울 수 있습니다.
- Conventional Commits
  - 연결 이유: 브랜치 병합 내역을 추적하고 가독성을 높이기 위해 전 세계적으로 통용되는 커밋 메시지 작성 표준입니다.
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: `feat(scope): message` 와 같은 형식의 구문을 통해 코드 히스토리 파악 및 문서 자동화를 어떻게 이룰 수 있는지 이해할 수 있습니다.

### Deeper Research Questions
- Trunk-Based Development를 성공적으로 적용하기 위해 필수적인 자동화 테스트 환경(CI)과 기능 플래그(Feature flags)의 구현 전략은 무엇인가?
- 소규모 팀이 단일 `main` 브랜치 전략을 사용할 때, 예기치 않은 버그가 배포되는 것을 막기 위한 GitHub 저장소의 브랜치 보호 규칙(Branch Protection Rules) 최적화 방법은 무엇인가?
- 장기 체류 브랜치(Long-lived branch)에서 발생하는 거대한 병합 충돌을 피하기 위해 `main` 브랜치의 최신 내용을 가져올 때 `merge`와 `rebase` 중 어떤 방식이 이력 관리에 더 효과적인가?
- 원자적 커밋(Atomic Commits)을 강제하는 정책이 Pull Request 리뷰 시간과 버그 추적성에 어떠한 정량적/정성적 영향을 미치는가?
- Git Flow 방식에서 GitHub Flow 방식으로 팀의 워크플로우를 마이그레이션할 때 예상되는 혼란 요소와 이를 해결하기 위한 CI/CD 파이프라인의 재구성 방법은 무엇인가?

### Practical Application Contexts
- **Implementation:** 새로운 기능 개발을 시작할 때, 최신 `main` 브랜치에서 `feature/티켓ID-간단한-설명` 이름으로 브랜치를 파생하고, 원자적 단위로 작은 커밋을 자주 기록합니다.
- **System Design:** 프론트엔드 모듈 아키텍처 설계 시, 독립적인 피처(Feature) 폴더별로 브랜치를 나누어 개발함으로써 특정 코드 영역 밖으로 병합 충돌의 폭발 반경(Blast radius)이 퍼지지 않도록 합니다.
- **Operation / Maintenance:** 브랜치가 `main`으로 병합되는 즉시 GitHub Action 등 CI 서버에서 자동으로 린트(ESLint), 테스트(Jest), 포맷팅을 수행하도록 방어막을 구축하여 메인 브랜치의 배포 가능한 상태를 영구적으로 유지합니다.
- **Learning Path:** Git의 기초 명령어를 습득한 후, 소규모 팀 단위의 Feature Branch Workflow를 실습하고, 이후 CI/CD 도구를 연동한 Trunk-Based 환경으로 발전하는 순서로 학습합니다.
- **My Project Relevance:** 3~5인 규모의 프로젝트에서 무거운 Git Flow의 도입을 지양하고, '단기 기능 브랜치 → PR 및 1인 이상 피어 리뷰 승인 → Squash Merge 및 브랜치 즉시 삭제'라는 단순화된 룰을 적용하여 개발 속도와 코드 품질을 동시에 챙깁니다.

### Adjacent Topics
- Continuous Integration / Continuous Deployment (CI/CD)
  - 확장 방향: 브랜칭 전략에 의해 트리거(Trigger)되어 실행되는 빌드, 테스트, 배포 파이프라인의 자동화 프로세스를 깊이 알아봅니다.
- [[Feature-Sliced Design (FSD)|Feature-Sliced Design (FSD)]]
  - 확장 방향: 도메인과 기능 단위로 코드를 분리하는 프론트엔드 아키텍처 방법론으로, 브랜치를 기능별로 나눌 때 충돌을 물리적으로 최소화하는 코드 구조 설계법을 탐구합니다.

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