브랜치 전략 (Branch Strategy) 1.1 주요 브랜치 master: 프로덕션(배포)용으로 사용되는 최종 안정 브랜치 (주 1회) develop: 개발이 완료된 기능들을 합치고, QA를 거친 뒤 최종적으로 `master` 브랜치로 병합되는 브랜치 1.2 보조 브랜치 feature/: 새로운 기능 개발이나 개선 작업에 사용 예) `feature/cmyk32`, `feature/cmyk24` hotfix/: 프로덕션에서 발견된 긴급 버그 수정에 사용 예) `hotfix/issue32`, `hotfix/issue24` 1.3 브랜치 생성 및 종료 작업 전 `develop` 브랜치에서 새로운 `feature/` 브랜치를 생성 작업 완료 후 PR(Pull Request)을 열고 reviewer를 지정 reviwer는 code reivew가 완료된 브랜치를 `develop` 브랜치로 머지 긴급 수정 사항 발생 시, `master`에서 `hotfix/` 브랜치를 생성 후 수정 완료 시 `master`과 `develop` 두 브랜치에 모두 병합 커밋 규칙 (Commit Convention) 2.1 Commit message 구조 ``은 커밋 유형을 나타내며 아래 중 하나여야 한다. 2.2 Commit message 규칙 제목 Header 제목과 본문을 빈 행으로 구분한다. 제목은 50글자 이내로 제한 제목의 첫 글자는 대문자로 작성 제목 끝에 마침표 넣지 않기 제목은 명령문으로 사용하며 과거형을 사용하지 않는다 본문 Body 선택 사항 본문의 각 행은 72글자 내로 제한 본문은 어떻게보다 무엇을, 왜에 맞춰 작성하기 바닥글 footer 선택사항 이슈를 추적하기 위한 ID를 추가할 때 사용 `해결` 해결한 이슈 ID `관련` 해당 커밋에 관련된 이슈 ID `참고` 참고할만한 이슈 ID 커밋 예시 Pull Request 규칙 3.1 리뷰어 지정 (Reviewer Assignment) > `junni01kim` > `6keem` > `KJH0506` > `HSJNYLee` 지정된 코드 리뷰어가 리뷰 진행 기능 개발 시, 해당 코드에 관계가 있는 사람 혹은 해당 모듈(화면/UI/비즈니스 로직)에 대한 이해도가 높은 사람 리뷰어로 지정 긴급 수정(`hotfix/` 등)의 경우, 리뷰가 지연되지 않도록 가능한 한 빨리 리뷰어를 배정하고 리뷰가 완료되는 대로 머지 리뷰어가 제안하는 수정 사항이 있으면, PR 작성자는 반드시 검토 후 반영 여부를 결정하고, 필요한 경우 재리뷰 요청 3.2 PR 양식 (Pull Request Template) PR을 생성할 때, 반드시 PR 템플릿을 사용하여 아래 항목을 명시 예시 템플릿

에셋 폴더 assets/ 앱에서 사용하는 모든 에셋 파일을 정리합니다. 예: 폰트, 이미지, 아이콘, JSON 파일 등 `font/` : 커스텀 폰트 파일(ttf, otf 등) `icon/` : 앱에서 사용하는 아이콘 파일(svg, png 등) `image/` : 일반 이미지 리소스(jpg, png 등) 주의: `pubspec.yaml` 파일의 `flutter:` 섹션에서 `assets/`에 대한 경로를 선언해주어야 앱에서 정상적으로 사용 가능합니다. 코어 폴더: lib/ `main.dart` Flutter 앱의 진입점(Entry Point)입니다. `runApp(MyApp())`을 호출하여 앱을 실행합니다. `MultiProvider` 설정이 필요 없으며, `ProviderScope`로 Riverpod 상태를 감쌉니다. `models/` 데이터 모델을 정의하는 폴더입니다. 예: `UserModel`, `ProductModel` 등 주로 JSON 직렬화/역직렬화, 데이터 클래스, 엔티티를 정의합니다. `providers/` Riverpod 패턴을 활용해 상태 관리 로직을 담당합니다. `ChangeNotifier` 대신 `StateNotifier` + `StateNotifierProvider를` 사용해 상태를 관리합니다. 예: `UserProvider`, `AuthProvider`, `ThemeProvider` 등 `screens/` 앱의 UI 화면(Page, Screen)을 담당합니다. 예: `HomeScreen`, `LoginScreen`, `ProfileScreen` 등 각 스크린에서 `ConsumerWidget` 또는 `Consumer`를 사용해 Riverpod 상태를 구독하고 UI를 업데이트합니다. `services/` 비즈니스 로직, API 통신, 데이터베이스 접근 등 핵심 로직을 처리합니다. 예: `ApiService`, `AuthService`, `LocalStorageService` 등 Riverpod의 ref.read(...)를 사용해 서비스 로직과 상호작용할 수 있습니다. `utils/` 재사용 가능한 유틸리티 코드(함수, 상수, 포맷터 등)를 보관합니다. 예: `constants.dart`(상수), `validators.dart`(입력값 검증), `date_formatter.dart`(날짜 포맷) 등 특정 화면이나 로직에 국한되지 않고, 전역적으로 사용할 수 있는 헬퍼 코드가 들어갑니다.

공식문서를 참고하여 작성 하였습니다. 식별자 (Identifiers) Dart에서는 식별자를 세 가지 방식으로 사용합니다. 1.1. UpperCamelCase 설명: 각 단어의 첫 글자를 대문자로 작성합니다. 용도: 클래스, enum, typedef, 타입 매개변수 등 예시 (Good): 1.2. lowerCamelCase 설명: 첫 단어는 소문자, 이후 단어는 첫 글자만 대문자로 작성합니다. 용도: 메서드명, 변수명, 상수 (상수도 lowerCamelCase를 선호) 예시 (Good) : 1.3. lowercase_with_underscores 설명: 모든 글자를 소문자로 작성하고, 단어 사이에 언더스코어(\_)를 사용합니다. 용도: 패키지, 디렉토리, 파일명, import 접두어 예시 (Good): 예시 (Bad): 1.4. 약어와 두문어 처리 긴 약어 (2글자 이상): 일반 단어처럼 취급하여 첫 글자를 대문자로 작성 예: Http (Hypertext Transfer Protocol), Nasa (National Aeronautics and Space Administration) 두 글자 약어: 영어에서 모두 대문자로 쓰이면 그대로 사용 예: ID, TV lowerCamelCase에서 약어가 앞에 올 경우: 모두 소문자로 작성 예: 순서 (Ordering) 2.1. 임포트 순서 규칙: dart: 임포트 package: 임포트 상대 경로 임포트 예시 (Good): 예시 (Bad): 2.2. Export 순서 규칙: 임포트 이후 별도의 섹션에 배치하며, 각 섹션은 빈 줄로 구분합니다. 예시 (Good): 예시 (Bad): 포맷팅 (Formatting) 3.1. 자동 포맷터 사용 설명: dart format 명령어를 사용하면 일관된 포맷팅을 유지할 수 있습니다. 예시 3.2. 한 줄 120자 제한 설명: 가독성을 위해 한 줄의 길이를 120자로 제한합니다. (특별한 경우 제외) 주의: 긴 URI, 파일 경로, 또는 멀티라인 문자열은 예외가 될 수 있습니다. 3.3. 중괄호 사용 설명: 모든 제어문(조건문, 반복문 등)에서 중괄호를 사용합니다. 예시 (Good): 예시 (예외): else가 없는 간단한 if 문은 한 줄로 작성할 수 있습니다 예시 (Bad):

NAVER의 java 코딩 컨벤션을 따라 작성되었습니다. Spring Boot 코드 컨벤션 프로젝트 구조 패키지 구조 도메인 별로 패키지를 분리하여 관리합니다. 예시: 네이밍 컨벤션 클래스/인터페이스 PascalCase (첫 글자 대문자) 예: `UserService`, `OrderController`, `ProductRepository` 메소드 camelCase (첫 글자 소문자) 예: `createUser()`, `findAllProducts()` 변수 camelCase 예: `userName`, `orderList` 상수 모두 대문자, 언더스코어로 단어 구분 예: `MAX_CONNECTIONS`, `DEFAULT_PAGE_SIZE` 코드 포맷팅 들여쓰기 Tab 또는 스페이스 4칸 사용 줄바꿈 및 공백 각 클래스, 메소드, 필드 사이에 적절한 공백을 두어 가독성을 높입니다. 긴 줄은 100~120자 이내로 작성합니다. 예시: 주석 작성 모든 주석은 한글 로 작성하여 팀원이 이해하기 쉽도록 합니다. 클래스/메소드 설명 Javadoc 스타일 주석을 사용하여 클래스, 메소드의 역할과 사용법을 설명합니다. 인라인 주석 코드의 복잡한 로직이나 주의사항이 있을 때 한 줄 주석(//)을 사용합니다. TODO 주석 앞으로 개선하거나 추가할 사항이 있을 때 // TODO: 형식으로 남깁니다. 예시: 예외 처리 전역 예외 처리 @ControllerAdvice를 활용하여 전역 예외 처리 로직을 작성합니다. 커스텀 예외 비즈니스 로직에 맞는 커스텀 예외를 정의하여 사용합니다.