우리 팀은 안정적인 서비스 운영과 효율적인 병렬 개발(FE 3명, BE 4명)을 위해, Jira 티켓 기반의 브랜치 워크플로우를 사용합니다. 모든 작업은 Jira 이슈 생성과 동시에 할당되는 자동화된 브랜치에서 진행됩니다.
1. 메인 브랜치 (Main Branches)
팀의 뼈대가 되는 브랜치로, 이 두 브랜치에는 절대 직접 커밋(Direct Commit)을 하지 않고 반드시 PR을 통해서만 병합합니다.
main브랜치 (Production)- 실제 운영 서버(고객 및 관리자 페이지)에 배포되어 있는 코드입니다.
- 언제든지 에러 없이 배포가 가능한, 가장 안정적인 상태를 유지해야 합니다.
dev브랜치 (Development)- 다음 버전 배포를 위해 팀원들의 새로운 기능이 모이는 중심 브랜치입니다.
- 로컬에서 작업을 시작할 때 항상 기준이 되며, 개발 서버 배포 및 통합 테스트가 이루어집니다.
2. 작업 브랜치 네이밍 규칙 (Work Branches)
새로운 기능이나 버그 수정 작업을 할 때는 Jira 이슈를 생성하고, 해당 티켓 번호(HSC-XXX)가 포함된 브랜치를 생성하여 작업합니다. 브랜치 이름의 접두사(Prefix)는 커밋 컨벤션의 Type과 동일하게 가져갑니다.
- 포맷:
{Type}/HSC-{티켓번호} - Type 적용 예시:
feat/HSC-413: 새로운 기능 추가 (프론트 UI 구현, 백엔드 신규 API 등)fix/HSC-415: 개발 중 발견된 일반적인 버그 수정refactor/HSC-420: 기능 변화 없는 코드 구조 개선chore/HSC-422: 설정 변경, 패키지 추가 등 잡무hotfix/HSC-416: 운영 서버(main) 긴급 장애 패치
3. 표준 개발 워크플로우 (feat, fix, refactor 등)
스프린트 내 일반적인 작업은 반드시 dev 브랜치를 기준으로 진행됩니다.
- Jira 티켓 발급: Jira에서 이슈 생성 후 ‘진행 중(In Progress)’으로 상태 변경 (브랜치 자동 생성 연동)
- 최신화: 로컬 환경의
dev브랜치를 최신 상태로pull받습니다. - 브랜치 체크아웃: 발급된 작업 브랜치(
ex. feat/HSC-413)로 이동하여 개발을 진행합니다. - 커밋 & 푸시: 작업 완료 후 커밋 컨벤션에 맞춰 커밋하고 GitHub에 푸시합니다.
- PR 생성: GitHub에서
feat/HSC-413→dev방향으로 Pull Request를 올립니다.
4. 핫픽스 워크플로우 (Hotfix) - [긴급 장애 대응]
운영 서버(main)에 치명적인 장애나 버그가 발생하여, 당장 불을 꺼야 할 때 사용하는 프로세스입니다.
- 티켓 발급: Jira에서 핫픽스 이슈를 생성하여
hotfix/HSC-416브랜치를 발급받습니다. - 기준 브랜치 변경 (중요): 핫픽스는 현재 개발 중인
dev가 아니라, 장애가 발생한main브랜치 최신본을 기준으로 분기(checkout)해야 합니다. - 긴급 수정: 버그를 수정한 후 빠르게 로컬 테스트를 진행합니다.
- 양방향 병합 (DB Sync & 코드 동기화):
- 핫픽스 코드를
main브랜치에 병합하여 운영 서버에 즉시 반영(장애 해결)합니다. - (주의!) 해결된 코드가 다음 정기 배포 때 옛날 코드로 덮어씌워지지 않도록, 반드시
dev브랜치로도 한 번 더 병합(Merge)하여 코드 형상을 일치시킵니다.
- 핫픽스 코드를