스파르타 7일차

챕터4-1 : Github 협업 - Fork & Pull Request 이해

fork, clone 차이

Pull Request 생성과 개념 이해

챕터5-1 : 프로젝트 관리하기 (2) - 브랜치 전략 1

Dev, Stage, Prod Branch 구성

📚 Git에서 Dev, Stage, Prod 브랜치 구성을 사용하는 이유는 개발, 테스트, 그리고 배포 단계를 명확히 구분하여 안정성과 협업 효율성을 높이기 위함입니다. 각 브랜치의 역할과 구성 방식은 다음과 같습니다.

1️⃣

Dev 브랜치 (Development Branch)

역할

• 새로운 기능 개발(feature)과 버그 수정(bugfix)을 포함한 모든 작업의 기반 브랜치입니다.
• 개발자들이 가장 활발히 작업하는 브랜치로, 실험적 코드와 아직 완전하지 않은 변경 사항도 포함될 수 있습니다.

특징

• 이 브랜치의 상태는 안정적이지 않을 수 있으며, 테스트가 완벽히 이루어지지 않은 상태의 코드가 포함됩니다.

병합 흐름

• 개발 완료 후, stage 브랜치로 병합.

2️⃣

Stage 브랜치 (Staging Branch)

역할

• 배포 전의 최종 테스트 환경을 제공하며, 통합 테스트(Integration Test)와 품질 보증(QA)이 이루어지는 단계입니다.
• 실질적으로 배포 준비가 완료된 코드를 포함합니다.

특징

• dev 브랜치에서 충분히 검증된 코드를 이 브랜치로 병합하여 테스트.
• 테스트 환경에서는 실제 운영 환경(Prod)과 유사한 설정을 사용하여 예상치 못한 문제를 미리 발견합니다.

병합 흐름

• dev → stage로 병합 후 테스트 진행.
• 테스트 통과 후, prod 브랜치로 병합.

3️⃣ Prod 브랜치 (Production Branch)

역할

• 실제 사용자가 접근하는 프로덕션 환경의 코드를 포함하는 브랜치입니다.
• 이 브랜치의 코드는 반드시 안정적이고, 배포 가능한 상태여야 합니다.

특징

• 사용자가 직접 사용하는 서비스의 모든 변경 사항은 이 브랜치에 반영됩니다.
• 긴급 수정이 필요한 경우, hotfix/ 브랜치를 사용하여 Prod 브랜치에서 작업 후 바로 병합할 수도 있습니다.
• 버전 태그(tag)를 통해 배포 이력을 관리하는 경우가 많습니다.

병합 흐름

• stage → prod로 병합하여 배포.

📚 master (최근 생성되는 브랜치에서는 모두 main), develop은 우리가 앞전에 봤기 때문에 스킵하지만, 여기서 hotfix, release, feature 3개 브랜치의 용도에 대해서는 이해할 필요가 있습니다.

feature 브랜치

역할

• 새로운 기능 개발을 위한 브랜치입니다.
• 보통 develop 브랜치에서 분기하여 작업을 시작하고, 개발이 완료되면 다시 develop 브랜치로 병합됩니다.

작명 규칙

• feature/login-page, feature/api-integration 등 기능 이름을 포함.

사용 시점

• 특정 기능이나 개선 사항을 독립적으로 작업.
• 코드 리뷰와 기본 테스트를 거친 후 develop 브랜치에 병합.

2️⃣

release 브랜치

역할

• 배포 전 최종 테스트 및 QA(품질 보증)를 위한 브랜치입니다.
• develop 브랜치에서 분기하며, 모든 버그가 수정되고 테스트를 통과하면 master 브랜치에 병합됩니다.
• 테스트 중 발견된 버그는 release 브랜치에서 바로 수정한 후 병합.

사용 시점

• 새로운 릴리스를 준비할 때.
• 안정화 작업 완료 후 master 및 develop에 병합.

3️⃣ hotfix 브랜치

역할

• 프로덕션에서 발생한 긴급 버그를 수정하기 위한 브랜치입니다.
• master 브랜치에서 바로 분기하며, 수정이 완료되면 다시 master와 develop 브랜치로 병합됩니다.

사용 시점

• 프로덕션에서 긴급한 수정이 필요할 때.
• 예: 치명적인 보안 결함, 서비스 중단 이슈 등.

작명 규칙

• hotfix/critical-bug, hotfix/payment-error 등.