협업 효율성과 코드 품질 유지를 위해 명확한 브랜치 전략과 규칙을 정하는 것은 중요합니다. 아래는 일반적인 팀 개발에서 활용되는 브랜치 룰 정리입니다.
1. 기본 브랜치 구조
main (또는 master)
├── develop
│ ├── feature/
│ ├── fix/
│ ├── refactor/
│ └── chore/
├── release/
└── hotfix/2. 브랜치 종류와 용도
| 브랜치명 | 용도 |
|---|---|
main | 배포 가능한 상태의 안정된 코드 |
develop | 다음 릴리스를 위한 통합 브랜치 |
feature/ | 새로운 기능 개발용 브랜치 |
fix/ | 버그 수정 브랜치 |
refactor/ | 리팩토링 브랜치 (기능 변화 없음) |
chore/ | 빌드, 설정 등 잡무 처리 |
release/ | 배포 준비 및 QA 대응용 브랜치 |
hotfix/ | 운영 중 긴급 수정 사항 처리용 브랜치 |
3. 브랜치 네이밍 규칙
feature/login,fix/crash-on-launch,refactor/button-style- 모두 소문자 사용, 단어는
-로 구분 - 카테고리/작업내용 형태
4. 병합(Merge) 규칙
| 병합 대상 | 방식 | 설명 |
|---|---|---|
feature → develop | Pull Request | 코드 리뷰 필수 |
release → main | PR 또는 Merge Commit | 배포 전 QA 완료 필요 |
hotfix → main, develop | PR 또는 직접 병합 | 운영 이슈 긴급 반영 |
5. 커밋 메시지 컨벤션 (선택 사항)
feat: 로그인 기능 추가fix: 런타임 오류 수정refactor: 중복 코드 제거
6. 브랜치 관리 팁
- 기능 단위로 브랜치 분기, 너무 오래 끌지 말 것
- 병합 전
rebase나pull --rebase로 충돌 최소화 - 병합 후 브랜치 삭제로 저장소 깔끔하게 유지
✅ 결론
- 브랜치 전략은 팀의 규모, 개발 방식에 맞게 유연하게 조정
- 일관된 네이밍과 PR 기반 병합을 통해 충돌 최소화 및 코드 품질 향상
iOS Dev