[일지] 2026.02.12

작업한 것

• in c

  • 브랜치 전략 수립 및 문서화

    # Git 브랜치 전략 (Git Branch Strategy)
    
    `in-c` 프로젝트의 효율적인 협업과 코드 품질 관리를 위해 **Simplified Git Flow** 전략을 사용합니다.
    
    ## 1. 브랜치 구조
    
    | 브랜치 유형 | 명명 규칙 | 설명 |
    | :--- | :--- | :--- |
    | **Main** | `main` | 제품 출시 및 배포용 브랜치. 항상 안정적인 상태를 유지해야 합니다. |
    | **Development** | `dev` | 다음 출시를 위한 개발 통합 브랜치. 모든 기능 구현의 기준점입니다. |
    | **Feature** | `feat/{기능명}` | 새로운 기능 개발을 위한 브랜치. `dev`에서 분기하며 완료 후 `dev`로 병합합니다. |
    | **Fix** | `fix/{이슈명}` | 버그 수정을 위한 브랜치. `dev`에서 분기하며 완료 후 `dev`로 병합합니다. |
    | **Hotfix** | `hotfix/{이슈명}` | 운영 환경(`main`)에서 발생한 긴급 버그 수정용. 완료 후 `main`과 `dev` 모두에 병합합니다. |
    | **Documentation** | `docs/{항목}` | 단순 문서 작업 등을 위한 브랜치. |
    
    ## 2. 작업 흐름 (Workflow)
    
    1. **작업 시작:** `dev` 브랜치에서 최신 코드를 가져옵니다.
       ```bash
       git checkout dev
       git pull origin dev
       ```
    2. **기능 브랜치 생성:** 작업할 기능 브랜치를 생성합니다.
       ```bash
       git checkout -b feat/notification-mvp
       ```
    3. **개발 및 커밋:** 작업을 진행하고 의미 있는 단위로 커밋합니다.
    4. **Push 및 PR:** 원격 저장소에 Push 한 후 GitHub에서 `dev` 브랜치로 Pull Request를 생성합니다.
       ```bash
       git push origin feat/notification-mvp
       ```
    5. **리뷰 및 병합:** 코드 리뷰를 거쳐 `dev` 브랜치에 병합합니다.
    6. **배포:** 주기적으로 `dev`를 `main`으로 병합하여 실서비스에 반영합니다.
    
    ## 3. 커밋 메시지 규칙
    
    - `feat:` 새로운 기능 추가
    - `fix:` 버그 수정
    - `docs:` 문서 수정
    - `refactor:` 코드 리팩토링
    - `test:` 테스트 추가/수정
    - `chore:` 가벼운 작업 (설정 변경 등)
    
    ---
    *이 문서는 프로젝트의 성장에 따라 업데이트될 수 있습니다.*
    

  • MVP 구현

    • Concert 정보 수집 기능 구현
      

      

이슈

• 여러 컴퓨터에서 협업하기 어려움
  • 나름 개발 가이드를 작성시키면서 했는데도 레퍼런스 문서가 없으니 내 의도와 다른 방향으로 많이 작성됨
    • ex) RTM 작성 방식, User flow → 거킨 시나리오 → 테스트 맵핑 등

다음 작업

• REQ-COLL-02 / 03 / 04

마무리

딸깍.. 딸깍..