# [[Git Branching Strategies]]

## 📌 Brief Summary
Git 브랜칭 전략은 소프트웨어 개발 팀이 코드 변경 사항을 효율적으로 관리하고 통합하기 위해 사용하는 체계적인 워크플로우입니다. 이 전략은 메인(main) 코드베이스의 안정성을 보호하면서 기능 개발, 버그 수정 등을 격리된 환경(브랜치)에서 수행할 수 있도록 돕습니다 [1-3]. 팀의 규모와 프로젝트 요구사항에 따라 Feature Branch Workflow, Trunk-Based Development, Git Flow 등 다양한 전략을 맞춤 적용하여 코드 충돌을 방지하고 협업 효율을 극대화할 수 있습니다 [3, 4].

## 📖 Core Content
*   **주요 브랜칭 전략**
    *   **Feature Branch Workflow (기능 브랜치 워크플로우)**: 2~5명 규모의 소규모 팀에게 가장 초보자 친화적이고 권장되는 방식입니다 [2, 4]. 메인(main) 브랜치는 항상 안정적이고 배포 가능한 상태로 유지하며, 새로운 작업이 필요할 때마다 메인에서 분기된 짧은 수명의 기능 브랜치를 생성하여 작업합니다 [1, 2, 5].
    *   **Trunk-Based Development (트렁크 기반 개발)**: 강력한 CI/CD 환경을 갖춘 숙련된 팀에 적합하며, 짧은 수명의 기능 브랜치를 통해 작고 잦은 커밋을 메인에 병합하는 방식입니다 [1, 4].
    *   **Git Flow & GitHub Flow**: Git Flow는 정기적인 릴리스가 필요한 대규모 프로젝트에 적합하지만 소규모 팀이 사용하기에는 너무 무거울 수 있습니다 [4]. 반면 GitHub Flow는 메인 브랜치로 직접 병합하여 배포를 단순화하는 유연한 전략입니다 [6, 7].

*   **핵심 규칙 및 모범 사례 (Best Practices)**
    *   **브랜치 명명 규칙**: 브랜치 이름은 서술적이고 짧게 유지해야 합니다(예: `feature/user-auth`, `bugfix/login-error`) [8-10]. 이슈 트래커의 티켓 ID(예: `PROJ-123`)를 포함하면 코드 변경 사항과 비즈니스 요구사항 간의 추적성을 크게 높일 수 있습니다 [11, 12].
    *   **커밋 규칙 (Conventional Commits)**: 커밋은 의미 있는 작은 단위로 자주 수행해야 합니다 [9, 13]. `feat`(새 기능), `fix`(버그 수정), `docs`(문서), `refactor`(리팩토링), `chore`(유지보수) 등의 일관된 접두사를 사용하여 커밋의 목적을 명확히 하는 것이 좋습니다 [14-16].
    *   **Pull Request (PR) 및 병합**: 작업이 완료되면 반드시 PR을 생성하여 최소 1명 이상의 동료 리뷰와 CI/CD 테스트 통과를 거친 후 병합해야 합니다 [11, 13, 17]. 깔끔한 커밋 히스토리를 유지하기 위해 'Squash Merge(스쿼시 병합)'를 사용하는 것이 좋으며, 병합이 완료된 기능 브랜치는 즉시 삭제하여 저장소를 정리해야 합니다 [11, 13, 18].

*   **피해야 할 안티 패턴 (Anti-Patterns)**
    *   보호되어야 할 메인(main) 브랜치에 직접 코드를 커밋하는 행위 [19, 20].
    *   수명이 너무 긴 기능 브랜치를 방치하여 거대한 병합 충돌(Merge Conflict)을 유발하는 행위 [21, 22].
    *   코드 리뷰를 건너뛰거나, CI 테스트를 통과하지 못한 깨진 코드를 병합하는 행위 [20, 22].

## 🔗 Knowledge Connections
- **Related Topics:** [[Conventional Commits]], [[Pull Request Workflow]], [[CI/CD Pipeline]]
- **Projects/Contexts:** [[Frontend Team Collaboration]], [[Small Team Development]]
- **Contradictions/Notes:** 대규모 프로젝트에 자주 쓰이는 'Git Flow' 전략은 2~5명 규모의 소규모 팀에게는 프로세스 오버헤드가 커서 부적합하며, 대신 더 가벼운 'Feature Branch Workflow'나 'Trunk-Based Development'를 사용하는 것이 실무적으로 훨씬 권장됩니다 [1, 4, 23].

---
*Last updated: 2026-04-26*