1. 개발 환경 및 규칙 | 브랜치 전략
: 아직 미정
여러 개발자가 협업하기 위해서, 코드를 나누고, 합치는 방식에 대한 규칙을 의미합니다.
## 왜 필요한가?- 협업 과정에서 어떤 개발자가 어떤 작업 중인지 확인 용이
- 불완전한 코드가 배포되는 것을 방지
- 기능 개발 / 버그 / 버전 관리 등의 작업을 명확하게 분리 즉, 혼란을 줄이고 품질을 높이기 위한 개발 규칙입니다.
많이 쓰이고, 여러 종류의 브랜치를 사용하는 것이 특징입니다.
| 브랜치 명 | 역할 |
|---|---|
| main | 실제 배포 된 코드 |
| develop | 개발 중인 코드 (개발 서버에 배포) |
| feature/* | 작은 단위 개발 용 (ex. feature/sign-up, feature/#123) |
| release/* | 배포 준비용 브랜치 (해당 브랜치가 main에 merge) |
| hotifx/* | 긴급 수정용 브랜치 |
- main → 새 브랜치 생성 (예: feature/sign-up)
- 브랜치에서 작업 & 커밋
- GitHub에 PR(Pull Request) 생성
- 코드 리뷰 → 테스트 완료
- main에 머지 → 바로 배포 가능
- 브랜치 종류가 적어 단순하고, 빠른 개발에 용이합니다.
- 큰 릴리스 개념이 없고, 작은 변경을 자주 배포할 수 있습니다.
GitHub에서 제안 된 간단한 전략입니다.
지속 배포를 지향하는 프로젝트에 적합합니다.
| 브랜치 명 | 역할 |
|---|---|
| main | 항상 배포 가능한 상태 유지 |
| featur/* | 작은 기능 개발 |
- main → 새 브랜치 생성 (예: feature/sign-up)
- 브랜치에서 작업 & 커밋
- GitHub에 PR(Pull Request) 생성
- 코드 리뷰 → 테스트 완료
- main에 머지 → 바로 배포 가능
- 브랜치 종류가 적어 단순하고, 빠른 개발에 용이합니다.
- 큰 릴리스 개념이 없고, 작은 변경을 자주 배포할 수 있습니다.