📢 팀 프로젝트 브랜치 전략(Branch Strategy) 표준 적용 안내

[frydaynar]

✅ Branch Strategy (브랜치 전략)

1. 기본 흐름 (Workflow)

우리 프로젝트는 다음의 표준 흐름을 준수하여 기능을 개발하고 통합합니다.

feature → dev → main

2. 브랜치 종류 및 용도

각 브랜치는 지정된 목적에 맞게 운영되어야 합니다.

브랜치	용도
main	최종 배포 및 서비스 운영을 위한 브랜치
dev	모든 팀원들의 작업이 통합되는 중심 개발 브랜치
feature/*	Frontend, Backend, DB, AI Agent 등 개별 기능 개발을 위한 브랜치
bug/*	기능 오류 수정 및 버그 대응을 위한 브랜치
update/*	단순 갱신 (의존성 패키지 업데이트, 설정 변경 등)을 위한 브랜치
refactoring/*	기존 동작은 유지하면서 코드 구조를 개선하기 위한 브랜치
ts/*	기술적 난제 해결 로직, POC(개념 증명) 및 의사결정 기록을 위한 브랜치 (Trouble Shooting)
release/*	산출물 배포 및 버전 관리를 위한 브랜치
docs/*	WBS 업데이트, 가이드라인 작성 등 문서화 작업을 위한 브랜치

3. 브랜치 명명 규칙 (Naming Convention)

브랜치 이름만으로도 작업 내용과 담당자를 식별할 수 있도록 아래 형식을 준수합니다.

• 형식 : 타입/기능명_본인이니셜 (소문자 권장)
• 작성 예시 :
  • feature/partner-dashboard-ui_lnr
  • bug/db-connection_ihs
  • update/npm-packages_nyj
  • refactoring/auth-module_nyj
  • ts/ocr-processing-poc_ihs
  • release/v0.1.0 (버전 관리 브랜치는 이니셜 생략 가능)

4. 운영 원칙 (Strict Rules)

실무형 제품 팀(Product Team) 수준의 협업을 위해 아래 규칙은 절대적으로 준수합니다.

1. 선(先) Issue 생성 원칙
   이슈 번호가 없는 브랜치는 생성할 수 없습니다. 항상 이슈를 먼저 만들고 브랜치를 파생시킵니다.
2. main 직접 Push 금지
   모든 코드는 반드시 Pull Request(PR)와 리뷰를 거쳐 dev 브랜치를 통해 통합되어야 합니다.
3. 리뷰 기반 Merge
   최소 1인 이상의 동료로부터 승인(Approve)을 받아야 병합이 가능합니다.
4. 브랜치 정리
   Merge가 완료된 작업 브랜치는 저장소의 청결을 위해 즉시 삭제합니다.
5. 작업 단위 분리
   유틸리티나 API 기준으로 브랜치를 최대한 세분화하여 작업 충돌을 방지합니다.

---

📎 관련 근거 및 문서

• [공지] 프로젝트 협업을 위한 GitHub Ground Rule 및 워크플로우 (v1.3)
• [Engineering Standards] 통합 개발 표준 및 보안 가이드라인

위 브랜치 전략은 우리 팀이 '실무형 Product Team' 으로서 협업하기 위한 핵심 약속입니다.
전 파트(Frontend, Backend, DB, AI Agent) 간의 긴밀한 협업이 필수적인 만큼,
브랜치 운영 규칙을 더욱 엄격히 준수하여 개발을 진행해 주시기 바랍니다

[mpsddd-commits]

확인했습니다