🍭 Git 커밋 메시지 구조

1. Git

1-1. Git-Flow

브랜치 전략 : feature (기능) > develop (개발) > main (배포)

• 디벨롭 브랜치 (Develop branch)
  • 통합 브랜치의 역할, default 브랜치로 설정함.
• 피처 브랜치 (Feature branch)
  • 기능을 개발하는 브랜치, develop 브랜치로부터 분기
  • 브랜치명은 'feature/#이슈번호-설명' 형태로 통일
  • 기능을 다 완성할 때까지 유지하고, 다 완성되면 develop 브랜치로 merge

1-2. 진행 순서

1. 진행할 Issue 생성한다.

2. feature branch 생성한다. (이때 브랜치 명은 “feature/#이슈번호-브랜치명” ex. feature/1-setting)

3. 피드백이나 도움이 필요할 때, 그리고 merge 준비가 완료되었을 때는 develop 브랜치로 Pull Request를 생성한다.

4. 기능에 대한 리뷰와 논의가 끝나면 해당 pr을 올린 사람이 확인 후 develop 브랜치로 merge한다.

5. 이전에 merge된 작업이 있을 경우 다른 branch에서 진행하던 작업에 merge된 작업을 pull 받아옵니다.

6. 종료된 issue와 pull request의 label을 관리합니다.

1-3. Issue

항상 작업을 시작하기 전 개발해야 하는 기능에 해당하는 Issue를 만들고 작업에 들어가야 하며, 목적을 간단히 작성하고 작업할 내용의 진행사항을 체크박스 형식으로 작성 합니다.

assignee, label을 적용합니다. assignee는 해당 issue 담당자, label은 작업 내용을 추가합니다.

1-3-1. Issue naming rule

[<Prefix>] <description>의 형식을 따르며 이때 Prefix는 commit tag를 따릅니다.

<aside> 🍭 ex) [feat] Amazon S3 연동 , [fix] Hospital Entity Column 수정

</aside>

1-3-2. Issue template

## Description 🍭
> 해당 이슈에서 해야할 작업 설명

##  To do 🍭
- [ ] 필요한 사항을 체크박스로 표시 후 완료 시 체크