-
Notifications
You must be signed in to change notification settings - Fork 4
팀프로젝트 그라운드 룰
ParkSeungHwan edited this page Oct 29, 2020
·
22 revisions
- Front-End
- Back-End
- Test
- eslint를 사용하여 코딩 스타일 통합
- 어떤 lint 스타일을 적용할 것인가?
- 기본 룰은 airbnb 스타일 사용. 추후에 불편한 rule을 추가하여 조정.
- 이슈, 마일스톤, 프로젝트로 관리하기
- 마일스톤 기간은 일주일.
- 각 이슈를 가져가서 작업하기
- 데일리 스크럼 때 어떤 이슈 맡을 것인지 얘기하기
-
Feat: 새로운 기능을 추가할 경우.
-
Fix: 버그를 고친 경우.
-
Docs: 문서 수정한 경우.
-
Style: 코드 포맷 변경, 세미 콜론 누락, 코드 수정이 없는 경우.
-
Refactor: 프로덕션 코드 리팩터링.
-
Test: 테스트 추가, 테스트 리팩터링 (프로덕션 코드 변경 없음).
-
Chore: 빌드 테스크 업데이트, 패키지 매니저 설정할 경우 (프로덕션 코드 변경 없음).
-
몇 명이상 approve 해야 merge 가능한지
- 본인 제외하고 최소 2명이 approve해야 merge한다.
-
퇴근시간 최대 21시❗️❗️❗️
-
브랜치 전략은?
fork 해서 작업한 내용 push -> 원본 저장소에 pr -> 리뷰후 merge
1 issue === 1 pr(to master) (뱅크샐러드-하루에-1000번-배포하는-조직-되기)
-
commit 단계에서 유닛테스트를 통과해야만 pass 되도록 설정해서 버그를 줄이면 좋을 것 같음.
-> githooks 로 처리 가능
-> pre-commit
commit -> lint-staged -> perttier -> eslint -> test -> done.
-
merge할 때 이슈 관리
이슈 처리를 완료하여 pr 요청을 보낸다.
pr 작성 시 리뷰어를 모든 팀원을 지정한다.
슬랙으로 @here로 pr 한 사실을 팀원에게 독촉한다.🤗🤗🤗
팀원은 코드를 보고 리뷰를 한다.🙆♂🙅♀
1️⃣ Week1
목표
데일리스크럼
회의
회고
2️⃣ Week2
목표
데일리스크럼
회의
회고
2️⃣ Week3
목표
데일리스크럼
회의
회고