Skip to content

팀프로젝트 그라운드 룰

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: 빌드 테스크 업데이트, 패키지 매니저 설정할 경우 (프로덕션 코드 변경 없음).

PR 규칙

  • 몇 명이상 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 한 사실을 팀원에게 독촉한다.🤗🤗🤗

팀원은 코드를 보고 리뷰를 한다.🙆‍♂🙅‍♀

Clone this wiki locally