💡 Git Branch 전략

📌 브랜치 전략 개요

🔹 경량화된 Git Flow 채택

작은 규모의 팀과 빠른 개발 주기에 적합한 경량 Git Flow 전략을 사용합니다.

🔸 브랜치 종류 및 역할

브랜치	설명
main	제품 수준의 안정된 코드를 유지하는 브랜치. 모든 기능이 완전히 통합되고 검증된 상태만 존재
develop	기능 개발의 통합 테스트용 브랜치. 팀원 개별 기능을 병합하여 주기적으로 테스트 수행
feature	각 단위 기능을 개발하는 브랜치. 완료된 기능은 develop 브랜치로 병합(Merge)

⚠️ release, hotfix 브랜치는 사용하지 않음

• 제품의 실제 배포가 없는 프로젝트이므로 hotfix 브랜치 불필요
• 품질 검사는 매주 정기적으로 수행되므로 release 브랜치 대신 develop에서 통합 테스트 수행

---

📌 브랜치 전략 보완점

☑️ 기존 Git Flow의 복잡성 개선

• 불필요한 브랜치 제거로 구조 단순화
• 작은 팀 환경에 최적화
• 빠른 반복 주기와 정기적인 테스트 사이클에 적합

---

📌 커밋 메시지 컨벤션

🔹 Commit Type

타입	설명
feat	새로운 기능 추가
fix	버그 또는 오류 수정
test	테스트 코드 추가 및 수정
perf	성능 개선
docs	문서 수정 (README 및 XLSX 등)

🔸 Commit 메시지 작성 원칙

• 제목은 50자 이내, 마침표 생략
• 명령문 형태로 작성
• 제목과 본문 사이는 한 줄 띄움
• 커밋 타입은 제목에 명시적으로 표기

☑️ 사용 이유
커밋 내역만으로 작업 내용을 명확히 파악할 수 있어 히스토리 추적 및 코드 리뷰 효율이 높아짐

---

📌 GitHub Push 정책

🔸 기능 개발 완료 시

• 로컬에서 기능 구현 및 단순 테스트 완료 후
• 해당 기능을 feature 브랜치에 Push

🔸 정기 테스트 주기

• 매주 화요일, feature 브랜치를 develop에 병합
• 병합 후 JUnit5 단위 테스트 수행
• 다음 주 화요일 전까지 모든 테스트 통과 필요

🔸 프로젝트 최종 병합

• 14주차 최종 발표 전까지:
  • develop 브랜치에서 모든 기능 테스트 완료
  • QA 문서 기준 기능 구현 및 동작 검증 완료
  • develop → main 최종 병합

---

📌 GitHub Pull 정책

☑️ 협업 전 Pull 우선

• Push 전에 반드시 GitHub에 변경 사항이 있는지 확인
• 변경 사항 존재 시 git pull로 최신 코드 반영 후 작업 시작