1️⃣ feature/* 브랜치를 사용하는 이유
✅ 장점:
- 기능 단위로 코드 관리 가능
- 로그인, 대시보드, API 연동 등 기능별로 브랜치를 나눠 개발하면 코드 충돌 최소화
- 롤백이 쉬움
- 특정 기능에 문제가 생기면 해당 브랜치만 롤백 가능
- 가시적인 개발 이력 관리
- GitHub에서 브랜치별 개발 과정을 명확하게 보여줄 수 있음 (포트폴리오에 긍정적 영향)
- 테스트 환경 분리
- 기능별로 독립적인 테스트 가능 (기능 A 개발 중 기능 B에 영향 없음)
2️⃣ 언제 feature/* 브랜치를 사용해야 할까?
| 상황 | 브랜치 전략 추천 |
|---|
| 작은 개인 프로젝트 (단순한 기능) | main 또는 develop 단일 브랜치로 충분 |
| 포트폴리오 프로젝트 (빅테크 대비) | ✅ feature/* 브랜치 활용 (개발 과정 관리 강조) |
| 복잡한 프론트엔드 구조 (대규모 기능) | ✅ feature/* 필수 (대규모 SPA, 상태 관리 복잡한 앱 등) |
| 빠른 프로토타이핑 또는 테스트 | develop 브랜치에서 바로 개발 |
⚡ 3️⃣ 프론트엔드 개발 브랜치 전략 예제
✅ Step 1: 기본 브랜치 구조
git checkout -b main
git checkout -b develop
✅ Step 2: 기능별 브랜치 생성 및 개발
✅ Step 3: 기능 병합 (Merge)
git checkout develop
git merge feature/login
git merge feature/dashboard
✅ Step 4: 배포 전 main으로 병합
git checkout main
git merge develop
git push origin main
4️⃣ 커밋 메시지 규칙 (프론트엔드 전용 예시)
feat: 새로운 기능 추가
feat: Add user authentication with JWT
fix: 버그 수정
fix: Correct API data mapping issue
refactor: 코드 리팩토링
refactor: Simplify Redux state management
style: UI 스타일 변경 (기능에는 영향 없음)
style: Update button hover effects
docs: 문서 수정
docs: Update README with API usage guide
📦 5️⃣ GitHub PR(Pull Request) 활용 (혼자 개발 시에도 효과적)
- 혼자 개발하더라도 GitHub에서 PR 작성을 통해 코드 리뷰 프로세스를 시뮬레이션할 수 있음
- PR 설명에 "무엇을 변경했는지", "어떤 이유로 수정했는지"를 명확히 작성하면 좋음.
## PR 내용
- 로그인 기능 구현
- JWT 토큰을 활용한 인증 로직 추가
- API 호출 시 인증 헤더 처리 로직 추가
## 테스트 방법
- `/login` 페이지에서 로그인 테스트 진행
- API 호출 시 올바른 토큰이 전송되는지 확인
6️⃣ 개발 환경에서 브랜치 전략 비교
| 항목 | 단일 브랜치 (main/develop) | 브랜치 전략 (main + develop + feature) |
|---|
| 간결성 | ✅ 간단하고 빠르게 개발 가능 | ❌ 브랜치 관리가 더 필요함 |
| 기능 관리 | ❌ 여러 기능이 섞여 있어 롤백이나 테스트 어려움 | ✅ 기능별로 독립적으로 관리 가능 |
| 코드 품질 관리 | ❌ 코드 충돌이나 관리 이슈 발생 가능 | ✅ PR, 코드 리뷰 등 체계적인 품질 관리 가능 |
| 포트폴리오 완성도 (빅테크 대비) | ❌ 단순한 Git 이력으로 보일 수 있음 | ✅ 체계적인 Git Flow로 전문성 강조 가능 |
📢 최종 정리
| 상황 | 추천 브랜치 전략 |
|---|
| 작은 개인 프로젝트 (빠른 개발) | main 또는 develop에서 바로 개발 |
| 포트폴리오 프로젝트 (빅테크 대비) | ✅ feature/* 브랜치 활용 (PR 시뮬레이션까지) |
| 복잡한 SPA 개발 (대규모 상태 관리) | ✅ feature/* 필수 (상태 관리, API 모듈화 등 명확히 관리) |