Github 컨벤션

브랜치	설명
main	Git Flow의 Main 브랜치와 동일하다. 항상 Stable한 상태여야 한다. ⇒Main 브랜치의 모든 커밋은 빌드가 되고 테스트를 통과해야 한다.
android-main	안드로이드의 Main 브랜치이다. 제약은 main 브랜치와 동일하다. 스프린트 주기마다 main 브랜치에 머지된다.
backend-main	백엔드의 Main 브랜치이다. 제약은 main 브랜치와 동일하다. 스프린트 주기마다 main 브랜치에 머지된다.
feature	새로운 기능을 개발하기 위한 브랜치이다. 안드로이드 팀은 android-main 브랜치에서, 백엔드 팀은 backend-main 브랜치에서 생성하며, Git Flow의 Feature 브랜치와 동일한 역할을 한다. Hotfix 작업도 해당 브랜치에서 진행한다. 기능을 명확하게 설명할 수 있도록 네이밍한다. 자동화된 CI 빌드를 통과하면 각 팀의 main 브랜치에 머지할 수 있다.

선택 이유
- 소규모 서비스를 개발하기에 Git Flow는 브랜치가 너무 복잡하다.
- 우선, 개발 기간이 촉박하기 때문에 Github Flow를 사용하다가 Level 4 유지보수 기간에 다른 브랜치 전략의 필요성을 느낀다면 그 때 사용할 예정이다.
기존 전략 변형
- 기존 main 브랜치는 사용하지 않는다.
- 백엔드는 backend-main을, 안드로이드는 andorid-main을 사용한다.
- 이유 : CI/CD를 할 때 브랜치 별로 빌드하기 위함.
- main 브랜치는 그대로 유지하고, 한 스프린트가 끝날 때마다 backend-main → main, android-main → main으로 머지한다.

Merge: [PR 제목(한글로)]

커밋 컨벤션

커밋 유형: 커밋 제목

- 세부 변경 내용1
- 세부 변경 내용2

#이슈 번호

feat	새로운 기능을 추가하거나, 기존 기능을 요구사항 변경으로 인해 변경한 경우
refactor	기능에 대한 변경 없이 코드 리팩토링 (파일명/클래스명/메서드명/변수명 변경 등)
fix	프로덕션 코드 버그 수정
test	테스트 코드 작성 및 수정 및 리팩토링
docs	문서 수정 (README, RESTDocs의 ASCII 파일 등)
design	UI 스타일 관련(for 안드로이드)
chore	설정 파일 관련 변경 사항(의존성 추가 등)
comment	필요한 주석 추가 및 변경
style	코드 포맷팅, 코드 정렬 순서 변경, import 옵티마이징