Home

Github Issue Tracker 1팀 위키

Member

Class	Nickname
BE	🚌 Alex, 🐱 Dion
FE	🦄 Reese

• Scrum-HackMD

API Document

Scrum

Ground Rule

⏰ TimeRule

• 오전 11시 스크럼 Google Meet을 사용, HackMD 사용
  • 컨디션, 하루 목표, 어제 공유했던 사항 회고를 한다.
  • 고민거리(개발에 관련되지 않은 사항도 👌)
• 스크럼 마스터를 매일 매일 돌아가면서 한다. (리즈-디온-알렉스)
  • 스크럼 마스터는 스크럼을 주도한다.
  • 스크럼 마스터는 meet Link를 공유해준다.
  • 스크럼 마스터는 스크럼 내용을 정리해서 github Wiki에 업로드한다.

🎄 브랜치 관리 & 📝커밋 관리

• Branch의 이름과 Commit의 이름은 항상 GitHub의 이슈번호로 시작합니다.
• FE(Front End) / BE(Back End)

🎄 브랜치 관리

• Branch: feature/[ClassName]-#{Issue No.}

  e.g. feature/BE-#1

---

• master: 배포용 브랜치
• dev: 개발 브랜치(Default)
• 이슈 단위로 개발한다.
• 개발 완료 후, 작업하던 브랜치에서 개발 브랜치(dev)로 PR를 생성한다.
• BE는 PR시 상대방은 reviewer에 할당하고, 할당받은 사람은 해당 PR을 확인 후, merge 한다.
• dev 브랜치로 merge 될 때, PR Body에서 해당하는 issue를 닫아준다.

  e.g. Resolve #1, Closed #1 ...

• review를 위해 리뷰 브랜치를 생성한다.

  e.g. FE-review-phase1

• 각자 클래스별 기능 개발 브랜치를 따로 두어서 리뷰어의 리뷰 를 잘 받는다.

  e.g. dev-FE-phase1

📝 커밋 관리

• Commit: [ClassName]-#{Issue No.} type: 커밋내용

  e.g. BE-#1 feat: 새로운 기능 추가

  타입	설명
  feat	새로운 기능 추가
  fix	버그 수정
  docs	문서 수정
  refactor	코드 리팩토링
  style	코드 포맷팅 (코드 변경이 없는 경우)
  test	테스트 코드 작성
  chore	소스 코드를 건들지 않는 작업(빌드 업무 수정)

기능 개발

🚀 Milestone

• 각 주차별로 Phase-{weeknum}을 붙여서 Milestone을 정의한다.
• 주의 시작에 간단하게 Milestone을 정의한다.

✅ Issue Template

---
name: "FE 피쳐 개발 이슈 템플릿"
about: FE 피쳐 개발 이슈 템플릿
title: "[FE] Title"
labels: "FE"
assignees: "reesekimm"
---

## 기능

- [ ] 세부 기능 내역 1
- [ ] 세부 기능 내역 2
- [ ] 세부 기능 내역 3

✅ PR Template

Fixes # (issue)

## 설명

변경사항이나 고쳐진 이슈에 대한 요약을 포함해주세요.
왜 고쳤는지에 대한 정보를 포함해주세요.
이 변경사항에 필요한 의존성 목록을 작성해주세요.

## 작업 유형

- [ ] 신규 기능 추가
- [ ] 버그 수정
- [ ] 관련 문서 업데이트 필요

## 체크리스트

- [ ] 이 PR의 코드들이 이 프로젝트의 스타일 가이드를 준수했는가?
- [ ] 내 코드에 대한 자기 검토가 되었는가?
- [ ] 이해하기 힘든 부분의 코드에 주석이 작성되었는가?
- [ ] 변경사항에 대한 문서를 작성하였는가?
- [ ] 변경사항이 새로운 경고를 만들어내지 않았는가?
- [ ] 변경사항이 효과적이거나 동작이 작동한다는 것을 보증하는 테스트를 추가하였는가?
- [ ] 새로운 테스트와 기존의 테스트가 변경사항에 대해 만족하는가?