1. Git Flow

기본 브랜치는 develop입니다.

• main에는 완벽한 결과물만 머지시킬 것 이므로, main 건드리기 금지!!!
• 저희는 develop 브랜치에서 저희의 이슈번호를 가진 feature 브랜치를 파고 거기서 개인의 작업을 하고, PR을 develop으로 날립니다~ (main 아님!)

<aside> 🌊 <순서>

1. 기능에 맞는 Issue를 생성

2. develop branch에서 해당 이슈번호를 가진 branch를 새로 생성(ex. feature/#이슈번호)

3. 2번에서 생성한 branch에서 작업을 진행

4. Add - Commit - Push - Pull Request 의 과정을 진행 (이 때!!! PR을 자신의 브랜치에서 develop브랜치로 보내야해요!! ‼️**main 절대 금지)**

5. Pull Request가 작성되면 작성자 이외의 다른 팀원이 Code Review

6. Code Review와 Code Review 반영까지 완료되면, Pull Request 작성자가 **로컬 develop branch**로 넘어가서 **원격 develop branch**를 pull 받기 (로컬 develop 브랜치 최신화 작업‼️)

7. 이 때, 컨플릭트가 생긴다면 해결

8. 다시 본인 로컬 작업 브랜치로 이동

9. 본인 로컬 develop 브랜치 우클릭 → merge into ‘본인 작업 브랜치’ (본인 작업 브랜치에 최신화된 develop 반영하는 작업)

10. 마찬가지로 컨플릭 생기면 해결하고 다시 머지 반영하고 push (push 하기 전에 한 번 실행해보기)

11. 깃허브 돌아가서 merge 가능한지 확인하고 merge

    • 머지할 때 ‼️ </aside>

<aside> 💡 누군가 브랜치를 머지했을 때 본인이 작업한 브랜치 devleop branch pull을 통해서 그때 그때 충돌해결해서 conflict 최소화 ➡️ 자신의 로컬 develop 브랜치에서 원격 develop 브랜치를 자주 풀 받자!! (최신화 자주자주!!!!!)

</aside>

<aside> 💡 1 issue 1 pull request: PR을 작은 단위로 가져가자, ISSUE를 작은 단위로 나누자

• issue랑 PR을 최대한 작게 작게 나누자 (코드리뷰 용이)
• 커밋 또한 작게 나누기
• PR은 최대한 자세하게!! </aside>

2. Issue Convention

<aside> 🍎 [<PREFIX>] <Description>

ex. [FEAT] 로그인뷰 전체 레이아웃 구현

</aside>

Issue & Commit & PR Prefix

• FEAT : 새로운 기능 구현
• ADD : Feat 이외의 부수적인 코드 추가, 라이브러리 추가, 새로운 View나 Activity 생성
• SETTING: 세팅 관련
• CHORE : 그 이외의 잡일/ 버전 코드 수정, 패키지 구조 변경, 파일 이동, 가독성이나 변수명, reformat 등