Github 규칙

협업 방법

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

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

Issue

제목

• 기능 관련 이슈: [기능분류] - [작업요약]
• 그 외 : [작업요약]

내용

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

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

<br/>

## 체크리스트

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

<br/>

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

Pull request

제목

• [작업요약]

내용

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

### 💁‍♂️ PR 개요

- 어떤 이유로 코드를 변경했는지
- 테크 스펙 [링크]()
- 프로덕트 스펙 [링크]()
- #{issue number}

<br/>

### 📝 변경 사항

- 어떤 부분이 수정되었는지

<br/>

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

- 관련 스크린샷 첨부

<br/>

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

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

<br/>

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

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

PR 생성 규칙

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

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

• 이슈 내용을 단일 PR로 구현 할 수 없을 때는 아래와 같이 진행한다

  • 이슈 내용이 커졌을 때

    작업 단위를 명확히 나눌 수 있다면 하나의 이슈에 대해 여러 개의 PR로 쪼갤 수 있다

    # example
    
    ISSUE : CI 테스트 통과를 위한 프로젝트 세팅
    
    - 첫번째 PR
      ESLint 테스트 통과를 위한 코드 수정
    
    - 두번째 PR
      테스트 코드 통과를 위한 테스트 코드 추가 및 기존 코드 수정
    
    - 세번째 PR
      빌드 테스트 통과를 위한 코드 수정
    

  • 사전 작업이 필요해서 현재 완성할 수 없는 경우

    1. 현재 이슈에 진행한 부분까지 PR을 작성하고 close한다

    2. 추후 이어서 구현을 할 때 추가 구현에 대한 이슈를 새로 생성 한 후, 이에 대한 설명들을 이슈 및 PR에 기재한다

    
    

    # example
    
    ISSUE : 내 제출 보기 버튼 임시 구현
    
    - PR
      현재 로그인 로직이 완성 되지 않았으므로 UI만 완성 후 첫번째 이슈 close
    
    
    
    ### 이후 로그인 로직 처리 완료 후 이슈 추가 생성
    
    
    
    ISSUE : 내 제출 보기 버튼 로그인 로직 연동
    
    - PR
      로그인 로직까지 연동한 다음, 두번째 이슈에 PR 작성 후 close
    
    

PR merge 규칙

• 팀원 한 명 이상 코드 리뷰 완료 시 merge한다.
• merge하지 않는 PR: closed하고, 이유를 코멘트로 남겨놓기
• merge 하기 전, 브랜치를 최신화시켜 conflict를 사전에 방지한다.

Projects

• Github의 Projects를 통해 작업 현황을 관리한다.
• 매주 회의 시간에 스프린트 단위의 Project를 생성한다.