Full Stack Engineer		Cloud Engineer		AI Engineer
harry.chang	doza.son	covy.shin	leo.park	summer.park	luna.jeong

집밥 요리사 (ZipBob Cook) - 1인 가구를 위한 AI 기반 요리 추천 서비스로, 사용자가 보유한 재료를 입력하면 AI가 적절한 레시피와 조리 방법을 추천해줍니다.

1. 제목과 본문을 빈 행으로 구분한다.
2. 제목은 50글자 이내로 제한한다.
3. 제목의 첫 글자는 대문자로 작성한다.
4. 제목 끝에는 마침표를 넣지 않는다.
5. 제목은 명령문으로 사용하며 과거형을 사용하지 않는다.
6. 본문의 각 행은 72글자 내로 제한한다.
7. 어떻게 보다는 무엇과 왜를 설명한다.

코드 리뷰의 경우 아래와 같은 프로세스를 지향합니다.

1. PR(Pull Request) 생성

   • 새로운 기능이나 버그 수정을 완료한 후, 해당 브랜치에서 main 브랜치로 PR을 생성한다.
   • PR 제목과 설명에 변경 내용을 작성한다.
   • PR Open

2. 리뷰어 할당

   • 팀 리더 또는 자동화된 도구를 통해 최소 1명의 리뷰어를 할당한다.

3. 리뷰어의 역할

   • 코드의 기능과 동작을 확인한다.
   • 코드 스타일과 일관성을 검토한다.
   • 성능 및 보안 문제를 파악한다.
   • 필요한 경우 개선 사항을 제안한다.

4. 코드 리뷰 방법

   • 코드 라인에 직접 코멘트를 남기거나 PR 코멘트로 남긴다.
   • 수정이 필요한 부분은 명확하게 설명한다.

5. 변경 요청

   • 리뷰어는 발견된 문제나 개선 사항에 대해 변경을 요청할 수 있다.
   • 변경 요청이 해결될 때까지 PR을 승인하지 않는다.

6. 수정 및 재검토

   • 작성자는 리뷰어의 피드백을 반영하여 코드를 수정한다.
   • 수정이 완료되면 리뷰어에게 다시 검토를 요청한다.

7. PR 승인

   • 모든 리뷰어가 PR을 승인하면 main 브랜치에 병합이 가능하여 작성자가 직접 PR을 닫아 병합한다.
   • PR Closed

8. 병합 후

   • 병합 후 CI/CD 파이프라인이 자동으로 실행되어야 한다.

1. main 브랜치

   • 배포 가능한 코드만을 포함한다.
   • 항상 안정적인 상태를 유지해야 한다.

2. develop 브랜치

   • 다음 배포를 위한 통합 브랜치이며 기능 개발이 완료된 후에는 이 브랜치로 병합한다.

3. feature 브랜치

   • 새로운 기능 개발을 위한 브랜치이며, feature/로 시작하고 기능 이름을 사용한다.
   • 예시: feature/member-api
   • 개발 완료 후 develop 브랜치로 병합한다.

4. hotfix 브랜치

   • 버그 수정을 위한 브랜치이며, hotfix/로 시작하고 버그 내용 또는 ID를 사용한다.
   • 예시: hotfix/fix-join-error
   • 수정 완료 후 develop 브랜치로 병합한다.

5. release 브랜치

   • 배포 준비를 위한 브랜치이며, release/로 시작하고 버전 번호를 사용한다.
   • 예시: release/1.0.0
   • 최종 테스트와 버그 수정을 거친 후 main 브랜치와 develop 브랜치로 병합한다.

1. 브랜치 생성

   • 새로운 기능, 버그 수정, 또는 릴리스를 시작할 때 적절한 이름 규칙에 따라 브랜치를 생성한다.

2. 브랜치 병합

   • 새로운 기능이나 버그 수정이 완료되면 PR을 생성하여 코드 리뷰를 받는다.
   • 간단한 내용의 수정일 경우 구두로 상의 후, 따로 PR은 생성하지 않는다.
   • 리뷰가 끝나면 PR을 develop 브랜치에 병합한다.

3. 충돌 해결

   • 병합 충돌이 발생하면 관련 팀원과 상의하여 해결해야 한다.

4. 브랜치 삭제

   • 병합이 완료된 브랜치는 삭제하여 브랜치를 관리한다.