🔀 깃 컨벤션

Github Flow

복잡한 관리 전략의 필요성이 적고 빠른 완성을 목표로 깃 관리에 적은 리소스를 쓰는 것이 개발에 용이하므로 Github-Flow를 채택한다.

• main : 개발이 완료된 산출물이 저장될 공간 -> 언제나 실행가능한 상태여야 한다.
• develop : 개발 작업이 이루어지는 브랜치, 이슈별/작업별로 브랜치를 생성하여 기능을 개발한다

브랜치 룰

1. main 브랜치에서의 작업은 원칙적으로 금지한다.
2. Pull Request를 작성한 후 카톡방에 코드리뷰 요청을 올린다.
3. 코드리뷰를 하며 서로의 코드를 이해하고 공부하며 성장합시다!
4. Merge시, 최신 main를 본인 브랜치에 먼저 Merge하여 로컬에서 Conflict를 해결한 뒤, 앱이 정상적으로 실행되는 지 빌드한 후 Merge한다.

브랜치 플로우

<1 이슈> - <1 브랜치> - <n 개의 PR> 의 대응 관계로 작성한다.

1. 하나에서 여러 PR을 포함할 수 있는 적당한 작업 단위로 Issue를 생성한다.
2. Miro에 해당 이슈의 진행상황을 추가한다.
3. Issue와 대응되는 브랜치를 하나 생성한다.
4. PR이 종료되어도 branch는 바로 삭제하지 않으며, Issue가 종료될 때 branch를 삭제한다.

코드리뷰

1. Reviewer

• 온화한 뉘앙스로 피드백을 단다.
• 유효한 리뷰가 될 수 있도록 염두에 두고 리뷰한다.

2. 커뮤니케이션 비용을 줄이기 위한 Princess N 룰

P1: 꼭 반영해주세요 (Comment)
P2: 반영해도 좋고 넘어가도 좋습니다 (Approve)
P3: 그냥 사소한 의견입니다 (Approve)