-
Notifications
You must be signed in to change notification settings - Fork 1
Branch strategy
Git Flow 기반 브랜치 전략
Git Flow는 develop, feature/*, hotfix/* 등의 여러 브랜치를 활용하여 안정적인 배포 및 협업을 지원하는 브랜치 관리 모델입니다.
이 전략은 긴 개발 주기에 적합하며, 주요 브랜치 관리 방식은 다음과 같습니다.
- main 브랜치는 언제나 배포 가능한 상태를 유지합니다.
- 새로운 작업은 반드시 feature 브랜치에서 시작합니다.
- 작업이 완료되면 Pull Request(PR) 를 통해 코드 리뷰를 요청합니다.
- 코드 리뷰가 완료되면 feature 브랜치를 main 브랜치에 병합(Merge)합니다.
- 필요한 경우 main 브랜치에서 배포를 진행합니다.
• 목적: 배포 가능한 안정된 코드를 유지하는 브랜치입니다. 언제든지 main 브랜치에서 직접 배포할 수 있도록 관리합니다.
• 사용 규칙: 직접 커밋을 금지하고, 오직 Pull Request(PR)를 통해서만 병합(Merge)되며, develop 브랜치를 거쳐 테스트를 완료한 코드만 병합됩니다.
• 배포: main 브랜치에 병합되면 자동으로 배포가 이루어질 수 있게끔 유지합니다.
• 목적: 다음 배포를 위한 개발 중인 코드를 유지하는 브랜치입니다. feature 브랜치에서 완료된 작업을 병합하고, 테스트를 거쳐 main 브랜치에 배포할 준비를 합니다.
• 사용 규칙: 직접 커밋을 금지하고, 오직 Pull Request(PR)를 통해서만 병합(Merge)됩니다. PR에는 최소 1명 이상의 승인을 필요로 합니다.
• 목적: 새로운 기능, 버그 수정 또는 기타 작업을 위해 사용하는 브랜치입니다. 각 작업은 개별 feature 브랜치에서 이루어집니다.
• 명명 규칙: feature/기능명 또는 fix/이슈번호-간단한-설명 형식으로 브랜치 이름을 작성합니다.
• 예시: feature/user-login, fix/123-bug-in-signup-page
• 생성 규칙: feature 브랜치는 항상 최신의 main 브랜치에서 생성합니다.
• 사용 규칙: 작업이 완료되면 Pull Request를 통해 main 브랜치에 병합되며, 병합 전 코드 리뷰를 통해 코드 품질을 검증합니다.
• 목적: 배포 중 긴급한 버그 수정이 필요할 때 사용하는 브랜치입니다. 주로 배포된 버전에서 발견된 심각한 문제를 빠르게 해결하기 위해 사용됩니다.
• 명명 규칙: hotfix/이슈번호-간단한-설명 형식으로 브랜치 이름을 작성합니다.
• 예시: hotfix/567-critical-login-bug
• 사용 규칙: 긴급한 수정 사항이 있을 때 main 브랜치에서 hotfix 브랜치를 생성하고, 수정 후 바로 main 브랜치에 병합합니다. 이후 main 브랜치를 배포하고 필요시 develop이나 feature 브랜치에도 변경 사항을 반영합니다
• 생성: 새로운 기능, 수정, 또는 긴급한 핫픽스를 진행할 때 필요한 feature 또는 hotfix issue를 생성, 해당 이슈의 Development 탭을 이용해 브랜치를 생성합니다.
• 삭제: Pull Request가 main 브랜치에 병합된 후에는 해당 feature 또는 hotfix 브랜치를 삭제합니다. 이를 통해 불필요한 브랜치가 남지 않도록 관리합니다.
• Pull Request(PR) 생성: 작업이 완료되면, PR을 생성하여 리뷰를 요청합니다. PR 생성 시 작업한 내용을 명확하게 설명하고, 연관된 이슈가 있다면 해당 번호를 링크합니다.
• 리뷰 및 승인: PR은 최소 2명 이상의 팀원이 리뷰하고 승인해야 합니다. 코드 리뷰 시, 코드 스타일, 성능, 안정성을 고려하여 피드백을 제공합니다.
• CI/CD 통합: PR이 생성되면 자동으로 테스트 및 빌드가 실행됩니다. 모든 테스트가 통과해야만 병합할 수 있습니다.