# [[Small Team Workflow]]

## 📌 Brief Summary
소규모 팀 워크플로우(Small Team Workflow)는 2~5명 규모의 개발 팀에 적합한, 가볍고 병합 충돌을 방지하는 버전 관리 전략입니다 [1, 2]. 복잡하고 무거운 Git Flow 대신 단순한 기능 브랜치(Feature-branch) 워크플로우나 단기 브랜치를 활용하는 트렁크 기반(Trunk-based) 개발을 주로 사용합니다 [2-5]. 'main' 브랜치의 안정성을 항상 유지하고, 수명이 짧은 브랜치에서 작업하며 풀 리퀘스트(PR)를 통한 동료 리뷰를 필수로 하는 것이 핵심입니다 [3, 6, 7].

## 📖 Core Content
* **전략 선택:** 소규모 팀에게는 프로세스 오버헤드가 큰 전체 Git Flow보다는, 최소한의 구조를 제공하면서도 가벼운 '단순 기능 브랜치 워크플로우' 또는 '단기 기능 브랜치를 동반한 트렁크 기반 워크플로우'가 권장됩니다 [2-5].
* **브랜치 및 네이밍 규칙:** 
  * `main` (또는 `master`) 브랜치는 항상 배포 가능하고 안정적인 상태를 유지해야 하며, 직접 푸시(direct push)는 엄격히 금지됩니다 [2, 3, 6, 8, 9].
  * 각 작업(Task)마다 `main`에서 브랜치를 생성하며, 브랜치는 수명이 짧아야(short-lived) 합니다 [3, 6, 10].
  * 브랜치 이름은 `feature/`, `bugfix/`, `chore/` 등의 접두사와 티켓 ID(예: `feature/PROJ-123-user-auth`), 짧은 설명을 결합하여 일관되게 명명합니다 [2, 6, 11-14].
* **커밋 규칙 (Atomic Commits):** 
  * 변경 사항은 하나의 논리적인 단위(Atomic)로 작게, 그리고 자주 커밋하여 리뷰와 히스토리 관리를 단순화해야 합니다 [3, 7, 11, 12].
  * 커밋 메시지는 '무엇'을 '왜' 변경했는지 명확히 설명해야 하며, `feat:`, `fix:`와 같은 컨벤션을 따르는 것이 좋습니다 [7, 12, 15].
* **풀 리퀘스트(PR) 및 병합 (Merge):** 
  * 아주 작은 변경이라도 항상 PR을 통해서만 병합해야 합니다 [11, 16].
  * PR은 가능한 작게 유지(예: 200줄 미만 권장)하고 변경 사항, 변경 이유, UI 변경의 경우 스크린샷 등을 포함해야 합니다 [8]. 
  * 병합 전에는 반드시 모든 테스트 및 CI 검사를 통과해야 하며, 최소 1명 이상의 동료 리뷰(Peer Review) 승인을 받아야 합니다 [7, 8, 11, 12, 16].
* **이력 관리 및 충돌 방지:** 
  * 커밋 히스토리를 깔끔하게 유지하기 위해 '스쿼시 병합(Squash Merge)'을 주로 사용하고, 병합이 완료된 기능 브랜치는 자동으로 삭제(Auto-delete)되도록 설정하는 것이 좋습니다 [7, 8, 11, 16]. 
  * 매일 작업을 시작하기 전에 최신 `main` 브랜치의 변경 사항을 동기화(Pull/Rebase)하여 대규모 병합 충돌을 예방해야 합니다 [4, 7].

## 🔗 Knowledge Connections
- **Related Topics:** [[Feature-branch workflow]], [[Trunk-based development]], [[Pull Request (PR)]], [[Git Flow]], [[Atomic Commits]]
- **Projects/Contexts:** [[Agile Software Development in Small Teams]], [[React Project Git Governance]]
- **Contradictions/Notes:** 소규모 팀 워크플로우의 명칭과 관련해 일부는 "단순 기능 브랜치 워크플로우(Simple feature-branch workflow)"라고 명명하고 [2, 6, 10], 다른 일부는 "단기 브랜치를 동반한 트렁크 기반 워크플로우(Trunk-based workflow with short-lived feature branches)"라고 칭합니다 [3, 16]. 하지만 보호된 main 브랜치 사용, 수명이 짧은 브랜치 운영, PR 리뷰 필수라는 실제 구현 규칙은 동일합니다. 두 접근 모두 Git Flow는 소규모 팀이 감당하기에 지나치게 무겁다는 점(Overhead)에 동의합니다 [3-5].

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