브랜칭 전략

1. Rules

1.1. Git Flow

1. 특정 작업에 대한 이슈를 생성한다.
2. Feature branch를 생성한다. => ex) feature/add-api-(이슈번호)
3. Add - Commit - Push - Pull Request - Merge의 과정을 거친다.
4. Merge 중 어려운 점이 있으면 같이 해결하거나 슬랙, zoom(줌)으로 의논한다.
5. 종료된 Issue와 Pull request의 Label과 Project를 관리한다.

1.2. ETC.

협업 시 준수해야 할 규칙은 다음과 같다.

1. develop branch 에서의 작업은 원칙적으로 금지한다.
2. 자신이 담당한 부분 이외에 다른 팀원이 담당한 부분을 수정할 때는 Slack을 통해 변경 사항을 전달한다.
3. 본인의 Pull Request는 같은 분야 사람과 논의 후에 Merge한다.
4. Commit, Push, Merge, Pull Request 등 모든 작업은 앱이 정상적으로 실행되는지 확인 후 수행한다.

2. Branch

Branch의 Naming Rule은 1.2.1을 따른다. Branch는 가능한 한 작업단위, 기능단위로 생성하며 이는 Issue를 기반으로 한다. 단, 같은 범위의 기능이라면 같은 브랜치를 사용한다. 예를 들면, 회원가입 기능 구현 시 아이디 중복 체크, 비밀번호 확인, 아이디 유효성 확인 등은 회원가입 하나로 구분한다.

2.1. Branch Naming Rule

• main : 개발이 완료된 산출물이 저장될 공간
• develop : feature 브랜치에서 구현된 기능들이 merge될 브랜치
• feature : 기능을 개발하는 브랜치, 이슈별/작업별로 브랜치를 생성하여 기능을 개발한다
• fix : 버그를 수정하는 브랜치

feature/기능설명-이슈번호, fix/기능설명-이슈번호

Branch를 생성하기 전 Issue를 먼저 작성한다. Issue 작성 후 생성되는 번호와 Issue의 간략한 설명 등을 조합하여 자동 생성되는 github의 양식을 따른다. ex) 1-feheader-component-만들기

3. Issue

• 작업 시작 전 Issue 생성이 선행되어야 한다. Issue는 작업 단위, 기능 단위로 생성하며 생성 후 표시되는 Issue Number를 참조하여 Branch Name과 Commit Message를 작성한다.

• 이슈 생성 시 Github 오른편의 Assignee, Label, Project, Linked Pull Requests 를 적용한다. Assignee는 해당 이슈의 담당자, Label에는 담당자를 추가한다. 이슈 관련 작업이 끝나면 Issue를 Close한다.

이슈는 아래 양식으로 탑재한다.

## Description

> TODO ADD Api 개발

## Progress

- todo 객체 유효성 판단...
- ...

4. Commit

4.1. Commit Rule

<Prefix>: <Description>-<Issue_Number>

• Feat 새 기능 추가
• Fix 버그 수정
• Design CSS 등 디자인 변경
• Style 코드 포맷 변경, 세미 콜론 누락, 코드 수정이 없는 경우
• Refactor 리팩토링
• Comment 주석 추가 및 변경
• Docs 문서 수정
• Test 테스트 추가, 테스트 리팩토링
• Chore 빌드 테스트 업데이트, 패키지 매니저를 설정(프로덕션 코드 변경 X)
• Rename 파일, 수정 수정하거나 옮기는 작업
• Remove 파일 삭제

4.2. Commit Example

feat: Room DB 기반 작업 추가-#7
docs: 리드미 파일에 개발자 추가-#24

5. Pull Request

Pull Request는 아래 양식으로 요청을 보낸다.

## Overview (Required)
- 

## Links
-

## Screenshot