Github 규칙

협업 방법

• 협업의 편리성을 위해 fork대신

  organization의 원본 저장소에서 같이 작업을 진행한다.

Issue - QA관련 이슈

제목

• 기능 관련 이슈

내용

• 템플릿 사용
• 하위 내용이 없을 경우에도, 제목을 남겨 놓는다.

## 개요
{ 업무에 대한 요약 및 설명 }

<br/>

## 체크리스트

{ 작업 체크리스트 }
- [ ] 리스트 1
- [ ] 리스트 2

<br/>

## 비고
{ 기타 내용, 의존성있는 작업 }

Pull request

제목

• 작업요약

내용

• PR 템플릿 사용
• 하위 내용이 없을 경우에도, 제목을 남겨 놓는다.
• 실행시켜보지 않아도 실행 결과를 알 수 있도록 상세하게 작성한다.

### 💁‍♂️ PR 개요

- 어떤 이유로 코드를 변경했는지
- #{issue number} (QA이슈)

<br/>

### 📷 스크린 샷 (선택)

- 관련 스크린샷 첨부

<br/>

### 🗣 리뷰어한테 할 말 (선택)

- 집중적으로 리뷰해주었으면 하는 부분 설명

<br/>

### 🧪 테스트 범위 (선택)

- 테스트 계획
- 테스트 완료 사항

PR 생성 규칙

• 이슈 하나당 하나의 PR을 원칙으로 한다.

  이슈 단위는 사전에 충분한 고려를 통해 하나의 PR로 구현이 완료될 수 있는 범위로 작성해야 한다.

• 하나의 이슈 구현에 여러 커밋이 생성되더라도, PR을 할때는 squash를 통해 커밋을 정리해서 PR을 작성한다

PR merge 규칙

• 팀원 한 명 이상 코드 리뷰 완료 시 merge한다.

• merge하지 않는 PR : closed하고, 이유를 코멘트로 남겨놓기

• merge 하기 전, 브랜치를 최신화시켜 conflict를 사전에 방지한다.

Projects

• 공유 Notion의 캘린더를 통해 작업 현황을 관리한다.

• 매주 회의 시간에 스프린트 단위 task를 생성한다.