Team Rule

⏰ Team Rules

📌 Commit message : git add . ⇒ git add 파일명 , 커밋메세지 세분화

📌 Branch name : 슬래시 사용

📌 Code convention : prettier 사용

📌 Task allocation : 알아서 잘 딱 센스있게

📌 Issue template : 유형별로 작성된 template에 맞게 알아서 잘 딱 센스있게

Project Schedule(dev)

시간	일정 내용	세부
09:00	standup	전 날 추가 작업한 부분 merge & pull, 그 날 할 일 공유
09:30	develop
12:00	lunch
13:30	meeting	오전 이슈 확인, 진행사항 확인(Optional)
14:00	develop
17:30	devlog	개인적으로 필요한 issue card 작성
18:00	code review	devlog 기반 공유, Meeting-log 작성
18:30	dinner
20:00	develop

💡 Issue Sharing Guide

• 틀릴 권리를 존중하고 자유롭게 팀원들과 의견, 생각 나누기
• 질문이 있거나 도움이 필요한 경우 충분히 생각을 한 후 질문하기
• 쿠션어 사용하기
• 답변에 최선을 다하여 해주기

⌛️ 의사 결정 Rule

• 시간이 여유로울 경우
  • 쉽게 결정이 안되는 사항이 있으면 잠시 10분 간 STOP하고 개인적으로 깊게 생각해볼 생각을 정리할 시간을 가지기
  • 잠시 해당 의제는 미루고 엔지니어님께 도움 요청 후 다음번 회의에 이어서 진행
• 시간이 급한 경우
  • 과반수인 경우 과반수 의견으로 진행
  • 동률인 경우 사다리타기

📖 Git

🔎 Git Rule

• dev 브랜치에서 'feature' 브랜치(branch) 생성
• 'feature' 브랜치에서 작업
• dev와 main에 직접 푸시 X / 풀 리퀘스트(Pull Request) O
• Pull Request 생성 전 잠재적인 충돌(conflict) 제거
• 병합(merge) 후, 로컬과 원격에 있는 feature 브랜치 삭제
• .gitignore 사용
• dev과 main 브랜치 보호

🔎 PR(Pull Request) Rule

• PR 제목

[Client / Server] / #15(issue number) / Type: Content

• PR 템플릿에 맞춰서 작성

🔎 Commit Message Rule

• 동명사X 관사X 명사O
• 부정문 Don't 사용
• 줄 바꿈을 통해서 제목과 본문을 구분
• 제목에 대문자를 사용
• 제목에 마침표 사용 X
• 제목에 명령법(imperative mood) 사용
• 오타 수정 = Fix typo

⌨️ Type Commit

Type	Description	Note
FIX	올바르지 않은 동작을 수정
ADD	코드나 테스트, 예제, 문서 등의 추가
REMOVE	코드의 삭제
USE	특별히 무언가를 사용해 구현
REFACTOR	전면 수정
SIMPLIFY	복잡한 코드를 단순화
UPDATE	개정이나 버전 업데이트	Fix와는 달리 Update는 잘못된 것을 바로잡는 것이 아님
IMPROVE	호환성, 테스트 커버리지, 성능, 검증 기능, 접근성 등 향상
MAKE	기존 동작의 변경
IMPLEMENT	코드가 추가된 정도보다 더 주목할 만한 구현체를 완성	Add에 비해 더 큰 단위의 코드 추가에 사용
REVISE	문서의 개정
CORRECT	문법의 오류나 타입의 변경, 이름 변경
ENSURE	무엇이 확실하게 보장받는다는 것을 명시
PREVENT	특정한 처리를 못하게 방지
AVOID	특정한 처리를 못하게 회피	‘Prevent’는 못하게 막지만, ‘Avoid’는 회피
MOVE	코드의 이동
RENAME	이름 변경
ALLOW	허용 표현
VERIFY	검증 코드
SET	변수 값을 변경하는 등의 작은 수정
PASS	파라메터를 넘기는 처리

📄 Workflow

👥 Member

1. mainstream 레포에서 fork해서 gitId/JoopJoop 레포 생성
2. 포크해온 gitId/JoopJoop 레포를 로컬에 clone
3. dev 브랜치를 기반으로 feature 브랜치 생성
4. feature 브랜치에서 코드 작성 전 mainstream dev 브랜치에 업데이트(merge)된 PR 있는지 확인
5. 업데이트(merge)된 PR이 있다면 자신의 dev 브랜치로 Fetch upstream 후 feature브랜치로 pull 당겨오기
6. feature 브랜치에서 코드작성 완료 후 로컬 feature 브랜치로 푸시
7. 로컬 feature 브랜치에서 upstream dev으로 PR 요청
8. (업데이트가 있을 때) mainstream 레포 dev 브랜치로부터 자신의 레포 dev브랜치에 Fetch upstream하여 최신화된 정보 동기화

브랜치 이름 형식

종류	사용패턴	특징
main	main	프로덕션 스냅샷 가장 최신의 배포된 버전
dev	dev	릴리즈 계획에 따라서 Github에서 기본 브랜치로 지정
feature	feature/이슈번호-이름 feature/1-branch-name	dev에 병합
hotfix	hotfix/이슈번호 hotfix/#911	메인에 병합

Module versions

• Node v16.15.0
• NPM 8.5.5
• Mongoose @6.2.8

💻 Code Style

Prettier

{
  "tabWidth": 2,
  "endOfLine": "lf",
  "arrowParens": "avoid",
  "singleQuote": false,
  "semi": true,
  "trailingComma": "all",
  "printWidth": 80
}