<aside> 💡

PR 문서에 관해서

• PR은 작게 문서는 크게
• 커밋도 작은 단위 !important </aside>

<aside> 💡

PR명 예시

• [Feat] 로그인 기능추가

commit 예시

• feat: 비즈니스 로직 추가 </aside>

<aside> 💡

깃허브 전략

<aside>

github flow

<aside>

1. 이슈 넘버로 브랜치 생성해서 작업해요
2. 작업이 끝나면 develop 브랜치로 PR
3. 최소 2명 이상의 approve 를 받아야 merge할 수 있어요. </aside>

</aside>

브랜치 운영

• main :
  • 배포가 가능한 브랜치
  • 모든 작업이 완료되고 리뷰가 끝난 경우에 merge (마지막 단계)
• develop :
  • 개발이 진행되는 동안 기능 브랜치들을 머지하는 브랜치
• init/기능명/#issue-number :
  • 초기 세팅 브랜치
• feat/기능명/#issue-number :
  • feature 브랜치로 새로운 기능 개발
  • 개발이 완료되면 develop 브랜치로 병합
• fix/기능명/#issue :
  • 버그 수정
• refactor/기능명/#issue-number :
  • 개발된 기능 리팩토링

merge 한 브랜치

• merge한 브랜치는 꼭 브랜치를 삭제해주자 !!

<aside> 💡

기능명은 케밥 케이스

</aside>

</aside>

<aside> 💡

브랜치 네이밍 컨벤션

• main
• develop

  • feature/#이슈번호-스크린ID-작업명

    • ex) feature/#9-goal_detail-ui
    • 스크린ID: 피그마 화면설계서에 나와있는 화면별 스크린ID로 통일.
    • 나의 목표 / 나의 이슈는 my_goal / my_issue 형태로

  • hotfix/#이슈번호-스크린ID-작업명

    (너무 애매한 경우에는 스크린 ID 생략)

  • 작업 후 develop 브랜치 등으로 merge가 되면 해당 feature, hotfix 브랜치는 생성한 사람이 삭제. </aside>

<aside> 📄

깃허브 라벨 사용 설명