브랜치 전략

브랜치 규칙

• main에 머지된 브랜치는 삭제합니다
• 브랜치 이름은 명확하게 작성합니다. ex)feature/#1
  • 명명 규칙:
    1. feature: 새로운 기능을 추가할 때 사용합니다.
    2. bugfix: 버그 수정을 위한 브랜치 이름입니다.
    3. hotfix: 긴급한 버그 수정을 위한 브랜치 이름입니다.
    4. refactor: 코드 리팩토링을 위한 브랜치 이름입니다.
    5. release: 배포 준비를 위한 브랜치 이름입니다.
    6. experiment: 새로운 아이디어나 기술 실험을 위한 브랜치 이름입니다.
    7. docs: 문서 작업을 위한 브랜치 이름입니다.
    8. chore: 자잘한 수정이나 설정 변경 등을 위한 브랜치 이름입니다.
• 하나의 브랜치에서는 하나의 작업만 합니다

PR 컨벤션

팀원들이 일관된 방식으로 풀 리퀘스트(PR)를 작성하고 검토할 수 있도록, 다음의 PR 컨벤션을 따릅니다.

PR 제목

• PR 제목은 간결하고 명확하게 해당 PR의 목적을 표현해야 합니다.
• PR 제목 형식은 이슈 제목과 유사한 형식으로 작성됩니다.
  • 형식: [카테고리/#이슈번호] PR 제목
  • 예시: [Feature/#101] 로그인 페이지 UI 구현

PR 작성 가이드라인

• PR을 작성할 때는 아래 템플릿을 사용하여 필요한 정보를 제공합니다.

관련 이슈

• 이 PR과 관련된 이슈 번호를 명시합니다. 예: close #4

작업 내용

• 해당 PR에서 구현된 기능, 수정된 버그, 또는 기타 변경 사항을 상세히 설명합니다.

참고 사항

• 리뷰어가 리뷰할 때 유의해야 할 사항이나 생각해볼 문제를 기재합니다.

테스트 결과

• 테스트 결과를 설명하고, 스크린샷, GIF, 또는 라이브 데모 링크를 첨부합니다. 스크린샷을 권장합니다.

체크리스트

• PR을 제출하기 전에 아래 항목들을 확인해 주세요:
• Reviewers를 지정했습니다.
• Assignees로 본인을 선택했습니다.
• 적절한 label을 선택했습니다.

PR 프로세스

1. PR 생성: 작업을 완료한 후, 변경 사항을 설명하는 PR을 생성합니다.
2. 코드 리뷰 요청: PR이 생성되면 팀원들에게 코드 리뷰를 요청합니다.
3. 코드 리뷰 진행: 리뷰어는 코드를 검토하고 피드백을 제공합니다.
4. 피드백 대응: PR 작성자는 리뷰어의 피드백을 반영하여 코드를 수정합니다.
5. 리뷰어 동의: 리뷰어는 수정된 코드를 다시 검토하고 동의합니다.
6. PR 병합: 필요한 승인 수가 충족되면, PR을 메인 브랜치에 병합합니다.