Ground Rule
- 2주동안 시범 운영 => 코어타임 : 2시 ~ 7시
- 코어타임 이후 : 자유롭게 개발하되 무리하지 않도록!
- 매일 오전 10시부터 약 15분정도 스크럼 진행
- 스크럼 매니저는 그 날 회의를 기록하고 위키에 업로드한다.
| 월 | 화 | 수 | 목 | 금 |
|---|---|---|---|---|
| 샛별 | 해람 | 진혁 | 민성 | 랜덤 |
- 코어타임 중의 PR은 되도록 즉시 리뷰 요청 (slack에 노티해주면 좋음)
- PR 사이즈는 최대한 200줄이 넘지 않게끔 중간 중간 PR을 날려주기
- 이슈를 생성할 때부터 작게 잘 나눠서 1이슈1PR을 날릴 수 있게!
- 머지 기준 : 남은 팀원 3명 모두에게 approve 받으면 PR을 날린 사람이 merge
- conflict 났을 때는 날린 사람이 resolve하고 머지
- 머지 완료된 브랜치는 머지한 사람이 삭제
- 코드리뷰는 정중하게 작성하기 + 코드와 나를 분리하기
- 리뷰이가 아닌 코드에 대한 리뷰
- 코드를 이해하지 못하면 커뮤니케이션을 통해 해결
- 리뷰가 틀려도 된다. 리뷰어의 의견을 무조건 따르지 않아도 되기 때문에 자신감을 가지고 적극적으로 리뷰
- 코드에 대한 피드백뿐 만이 아니라 칭찬도 잊지말자
- fork 여부는 원하는 대로 (민성님은 안전하게 fork를 뜬다..! 겁이 많아서...)
master : code freezing => deploy
develop : feature 브랜치 머지
${type}/${기능이름}${이슈번호} : 기능 개발하는 브랜치
ex.
feat/login-page#23
fix/be-get-label#33
# <타입>: <제목> (#1)
##### 제목은 최대 50 글자까지만 입력 ############## -> |
# 본문은 위에 작성
######## 본문은 한 줄에 최대 72 글자까지만 입력 ########################### -> |
# --- COMMIT END ---
# <타입> 리스트
# feat : 기능 (새로운 기능)
# fix : 버그 (버그 수정)
# refactor: 리팩토링
# style : 스타일 (코드 형식, 세미콜론 추가: 비즈니스 로직에 변경 없음)
# docs : 문서 (문서 추가, 수정, 삭제)
# test : 테스트 (테스트 코드 추가, 수정, 삭제: 비즈니스 로직에 변경 없음)
# chore : 기타 변경사항 (빌드 스크립트 수정 등)
# ------------------
# 타입은 영어로 작성하고 제목과 본문은 한글로 작성한다.
# 제목 끝에 마침표(.) 금지
# 제목과 본문을 한 줄 띄워 분리하기
# 본문은 "어떻게" 보다 "무엇을", "왜"를 설명한다.
# 본문에 여러줄의 메시지를 작성할 땐 "-"로 구분
# 관련된 이슈번호는 제목 맨 뒤에 추가한다. ex. (#1)
# ------------------
feat: 로그인 페이지 구현 (#1)
- 어쩌고 저쩌고
- 안넣어도 탓하기 없기~~