<aside> 😎 Table

• of Contents </aside>

<aside> 🔥

0. 우리팀 깃 컨벤션

Commit Message Convention

• Prefix 가 헷갈릴 때 참고해주세요!

<Prefix>/<Issue_Number>-<Description>

• FEAT : 새로운 기능 구현
• ADD : Feat 이외의 부수적인 코드 추가, 라이브러리 추가, 새로운 View나 Activity 생성
• CHORE : 그 이외의 잡일/ 버전 코드 수정, 패키지 구조 변경, 파일 이동, 가독성이나 변수명, reformat 등
• FIX : 버그, 오류 해결
• DEL : 쓸모없는 코드 및 파일 삭제
• MOD : xml (스토리보드) 파일만 수정한 경우
• MOVE : 파일 위치 이동
• DOCS : README나 WIKI 등의 문서 개정
• REFACTOR : 내부 로직은 변경 하지 않고 기존의 코드를 개선하는 리팩토링 시

Branch Naming

<prefix 소문자로>/<이슈번호>-<관련설명>

→ 대소문자 꼭 지켜주세요!

feature/2-HomeLayout
feature/10-HomeService

Issue

• Template 사용
• 라벨 달기
• 프로젝트 칸반보드 체크 필수

Pull Request

• Template 사용 (내용 꼼꼼하게 작성)
• Code Review 24시간 내로

Merge

• Approved 걸고 코리 받으면 자기자신이 Click

</aside>

1. Rules

1.1. Git Flow

1. Issue를 생성한다.
2. feature Branch를 생성한다.
3. Add - Commit - Push - Pull Request 의 과정을 거친다.
4. Pull Request가 작성되면 작성자 이외의 다른 팀원이 Code Review를 한다.
5. Code Review가 완료되면 Pull Request 작성자가 develop Branch로 merge 한다.
6. 종료된 Issue와 Pull Request의 Label과 Project를 관리한다.

1.2. Etc.

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

1. develop에서의 작업은 원칙적으로 금지한다. 단, README 작성은 develop Branch에서 수행한다.
2. 본인의 Pull Request는 본인이 Merge한다.
4. 빠른 협업 속도를 위해 Pull Request가 올라온 이후 **24시간 내에 Code Review**를 수행한다.
5. Commit, Push, Merge, Pull Request 등 모든 작업은 **앱이 정상적으로 실행되는지 확인** 후 수행한다.
6. README 수정을 위한 Commit 도배는 금지한다. 미리보기는 Preview를 통해 확인한다.

2. Branch

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

2.1. Branch Naming Rule