📌 브랜치 전략 & 협업 가이드

목차

1. 브랜치 구조
2. 브랜치 네이밍 규칙
3. 작업 및 PR 흐름 + PR 올리기 가이드 (작은단위 쪼개서)
4. 리뷰 및 머지 규칙
5. 배포 전략
6. 기타 협업 규칙

---

1. 브랜치 구조

main ← 배포 브랜치
  └── dev ← 팀 전체 기능 통합 브랜치
       └── feat/{이슈번호-기능명} ← 각자 기능 개발 브랜치
       └── fix/{이슈번호-기능명} ... 이렇게 브랜치 전략을 가짐.

유형	접두어	설명
기능추가	feat/	새로운 기능 개발
버그수정	fix/	버그 수정
리팩토링	refactor/	코드 구조 개선, 기능 변경 없음
UI 수정	style/	css나 ui 레이아웃 수정
문서 작업	docs/	README나 타 문서 수정
기타 작업	chore/	설정 파일 수정 등

---

2. 브랜치 네이밍 규칙

• feat/{이슈번호-기능명} 형식으로 작성
• 예시:
  • feat/10-login-form
  • feat/11-product-list
  • feat/12-cart-ui

---

3. 작업 및 PR 흐름

1. dev 브랜치 기준으로 새로운 브랜치 생성

   git checkout dev  # dev 브랜치로 이동
   git pull origin dev  # 최신 dev 반영  
   git checkout -b feat/기능명  # 개인 기능 개발 브랜치 생성
   

이때 pull 안 받고 바로 push 하면? conflict 에러날 수 있음., 그 이유는 다른 팀원이 feat 브랜치에서 기능 개발 후, pr 받고 dev에 merge 했는데, 내가 Pull 안 받고 작업을 하면 이미 merge된 dev와 내가 가져온 브랜치의 싱크가 맞지 않기 때문.

2. 작업 후 커밋 → 원격 저장소로 Push

   git push origin feat/login-form
   

3. GitHub에서 dev 브랜치로 Pull Request 생성

✅ PR 쪼개기 가이드

PR을 쪼개는 이유
  1. 코드리뷰가 간단하고 빠름
  2. 작업 충돌이 줄어듦
  3. 팀원들 간 진행 상황 공유가 쉬움
  4. 이슈나 버그 발생 시 원인 파악이 빠를 수 있음

그럼 어떻게 쪼개는 게 좋을까?

✨ 예시: "상품 검색 기능" PR 쪼개기

단계	작업 내용	PR 메시지 예시
1	검색창 UI 마크업 및 스타일 적용	feat: 검색창 UI 마크업 구현
2	검색어 입력값 상태 관리 (useState, onChange)	feat: 검색어 입력 상태 관리 로직 구현
3	검색 API 연결 및 연동 테스트	feat: 상품 검색 API 연동
4	검색 결과 리스트 화면 출력	feat: 검색 결과 리스트 출력 구현
5	디바운싱 적용 (lodash.debounce, custom hook 등)	feat: 검색 디바운싱 기능 추가
6	연관 검색어 추천 기능 구현	feat: 연관 검색어 추천 기능 구현
7	로딩 상태 및 에러 처리 추가	feat: 검색 로딩 및 에러 처리

---

💡 PR 올릴 때 팁

• PR 제목은 명확하고 간결하게! (feat:, fix:, refactor: 등 prefix 사용하면 좋아요)
• PR 설명에는 "무엇을 왜 구현했는지" 간단히 써주면 팀원 리뷰에 도움이 됩니다.

---

---

4. 리뷰 및 머지 규칙

•	팀원 중 2명 이상 approve 시 머지 가능
•	리뷰는 가볍게라도 꼭 해보기 (코드 리뷰 연습 겸)
•	PR 승인이 나면 작성자가 직접 dev 브랜치로 merge

⚠️ main 브랜치에는 직접 머지 ❌ 금지

---

5. 배포 전략

•	배포가 필요한 시점에 dev → main 으로 merge

---

6. 기타 협업 규칙

•	커밋 메시지는 자유지만, 한눈에 이해할 수 있도록 명확하게 작성
•	브랜치명, PR 제목도 기능이 잘 드러나도록 명확하게 작성

---