브랜치 전략

Git Branch 전략

master

프로덕션 서버(실제 사용자에게 서비스를 제공하는 환경) 배포용 Branch

• 모든 최종 릴리즈가 배포되는 브랜치로, 코드의 안정성과 신뢰성이 가장 중요하다.
• 배포 주기: 매주 일요일에 develop 브랜치의 코드를 master로 머지하여 프로덕션에 배포한다.
• 머지 조건: develop 브랜치의 코드가 주말 동안의 최종 테스트를 거쳐 문제가 없을 경우에만 머지한다.
• 긴급하게 해결해야 할 버그나 보안 취약점 발생 시 hotfix 브랜치에서 빠르게 반영한다.

hotfix

프로덕션 서버에서 발생한 중요한 문제를 해결하는 Branch

• 프로덕션 환경에서 즉각적인 대응이 필요한 버그나 보안 문제를 해결하는 데 사용한다.
• 핫픽스 프로세스: master 브랜치에서 hotfix 브랜치를 생성하여 문제를 수정하고, 수정된 내용을 검토 후 master와 develop 브랜치에 머지한다.
• 중요한 문제가 아닐 경우, 긴급성이 낮다면 다음 주 과업으로 이관하여 develop 브랜치에서 해결한다.

develop

staging 서버 배포용 Branch

• 새로운 기능 및 변경 사항을 통합하고 테스트하는 브랜치로, 프로덕션에 배포되기 전 최종 검증 단계의 역할을 한다.
• 배포 주기: 매주 금요일에 weekly 브랜치의 변경 사항을 develop 브랜치로 머지한다.
• 테스트: 주말 동안 staging 환경에서 최종 테스트를 진행하며, 테스트 중 발견된 이슈들을 해결한다.
• 모든 변경 사항이 충분히 검증된 후에만 master 브랜치로 머지하여 프로덕션에 배포된다.

weekly

로컬에서 테스트

• 주간 개발 작업의 통합 브랜치로, 일주일 간의 개발 결과물을 모아 테스트한다.
• 머지 조건: 새로운 기능이 추가되거나 수정된 코드가 포함된 PR(풀 리퀘스트)이 코드 리뷰를 거쳐 Approve(승인)되면, weekly 브랜치에 곧바로 머지한다.
• 매주 금요일에 develop 브랜치로 머지되며, 주말 동안의 테스트 과정을 통해 안정성이 검증된다.
• weekly 브랜치에 머지된 후 발견된 버그나 문제점은 즉시 해결하여 develop 브랜치로 반영한다.

feat 브랜치

새로운 기능 개발용 Branch

• 새로운 기능 추가, 개선 또는 변경 사항을 개발할 때 사용되는 브랜치로, 각 기능별로 별도의 feat 브랜치를 생성하여 작업한다.
• 이슈 생성: 브랜치를 생성하기 전, 어떤 기능에 관한 브랜치인지에 대한 이슈를 먼저 생성한다.
• 브랜치 생성: develop 브랜치에서 새로운 기능을 위한 feat/{#이슈번호}-{기능 이름} 브랜치를 생성한다.
• 개발 완료 후: 기능 개발이 완료되면 코드 리뷰를 위해 PR을 생성하고, 리뷰어의 승인을 받은 후 weekly 브랜치로 머지한다.
• 작업 방식: 각 기능의 개발이 독립적으로 진행되며, 완료된 후 통합을 위해 weekly 브랜치로 머지됨으로써 다른 기능과의 충돌을 최소화한다.
• feat 브랜치는 기능별로 관리되므로, 병합 전에 다른 feat 브랜치의 최신 변경 사항을 반영하여 충돌을 사전에 방지한다.