Team Convention - Seoul-InterViewer/InterViewer GitHub Wiki

To Do

• 모든 PR은 팀원들과 사전/사후 대화를 통해 진행합니다.
• 팀원들 간 이견이 발생하면 다수결로 진행합니다.
• 질문을 부담스러워하지 않고, 이해가 되지 않는 부분은 언제든 질문합니다.
• 각자의 작업 진행 상황은 정기적으로 공유해 팀 전체가 맥락을 이해할 수 있도록 합니다.
• 정기적으로 코드 리뷰를 진행하되, 리뷰는 일방적인 피드백보다 “대화” 중심으로 이뤄집니다.
• 기획, 디자인, 개발 간의 경계를 최소화하고, 아이디어는 누구든 제안할 수 있습니다.
• 건강 문제 등 부득이한 상황 발생 시 사전에 팀원들에게 알려주고 양해를 구합니다.
• TASK/FEATURE ISSUE가 올라오면 작업하던걸 잠시 멈추고 ISSUE 해결부터 합니다.

Not To Do

• 팀원들과 논의 없이 push나 merge를 하지 않습니다.
• 정해진 시간 약속을 지키며, 부득이한 경우엔 사전에 공유합니다.
• 개인적인 감정이 담긴 피드백은 지양하며, 언제나 건설적인 방향으로 의견을 주고받습니다.
• 다른 팀원의 작업을 무단으로 수정하거나 덮어쓰지 않고, 변경이 필요한 경우 먼저 공유합니다.

커밋 메시지 규칙

커밋 메시지는 제목과 본문으로 나누어 집니다. 한 줄만 작성해도 설명이 충분하다면 제목만으로도 괜찮습니다. 하지만 어떤 변경 사항이 있는지 맥락과 설명이 필요하다면 본문을 작성할 수 있습니다. 다음은 제목과 본문을 작성하는 규칙입니다.

• 커밋 메시지 앞에 붙이는 "feat", "init" 등의 접두사를 "커밋 타입" 또는 "커밋 컨벤션(Commit Convention)" 갖추기
• 제목과 본문을 한 줄 띄워 분리하기
• 제목은 70자 이내로 적기
• 제목 끝에 . 는 금지

주요 커밋 타입 예시:

feat: 새로운 기능 추가
fix: 버그 수정
docs: 문서 변경
merge: 브랜치 병합
style: 코드 스타일 변경(코드 기능에 영향을 주지 않는 변경)
refactor: 코드 리팩토링
test: 테스트 코드 추가 또는 수정
chore: 프로젝트의 환경 설정/구축, 빌드 프로세스나 보조 도구 변경
init: 프로젝트 초기화
build: 빌드 관련 변경사항
ci: CI 설정 파일 변경
schema: db 스키마 변경
migration: db 변경사항을 마이그레이션 sql파일로 저장
release: 버전 배포

중요: release는 반드시 커밋메시지에 버전(0.0.0 형식)을 작성해줘야합니다. 또한, release커밋 타입은 main브랜치에 PR을 올리기 전 최종 커밋에만 사용합니다.

release: v1.2.4 버전 배포

- 바뀐내용
- 바뀐내용2

실제 커밋 작성 예시:

feat: 사용자 로그인 기능 구현

- 로그인 폼 구현
- 스타일 수정

PR 규칙

PR은 진짜 급한 사항이 아니라면 반드시 본인 제외 최소 한명의 Approve 리뷰가 돠어야 병합하실 수 있습니다. Comment X

Comment는 코드 이외의 리뷰 (해당 코드 작동 확인메시지, 링크 체크, 디자인제안)을 할때 사용, 대부분의 경우에 전부 review를 사용합니다.

start a review하면 코드에다 다는 코멘트들이 임시저장돼서, 마지막에 submit을 하면 깔끔하게 하나의 리뷰로 남겨집니다.

PR 형식

📝 PR 제목

• feat / 브랜치명 - 간단한 작업내용

📝 PR 본문

반영 브랜치

• ex) INTER-01-Button -> dev

PR 타입(하나 이상의 PR 타입을 선택해주세요)

• 기능 추가
• 기능 삭제
• 버그 수정
• 의존성, 환경 변수, 빌드 관련 코드 업데이트

작업 내용

• 이번 PR에서 작업한 내용을 간략히 설명해주세요(이미지 첨부 가능)

테스트 결과 (선택)

• ex) 베이스 브랜치에 포함되기 위한 코드는 모두 정상적으로 동작해야 합니다. 결과물에 대한 스크린샷, GIF, 혹은 라이브 데모가 가능하도록 샘플API를 첨부할 수도 있습니다.

스크린샷 (선택)

리뷰 요구사항(선택)

• 리뷰어가 특별히 봐주었으면 하는 부분이 있다면 작성해주세요
• ex) 메서드 XXX의 이름을 더 잘 짓고 싶은데 혹시 좋은 명칭이 있을까요?

브랜치 이름 형식

종류	사용패턴	특징
main	main	프로덕션 스냅샷 가장 최신의 배포된 버전
develop	dev	릴리즈 계획에 따라서 Github에서 기본 브랜치로 지정
feature	INTER-00(지라 이슈번호)-기능명(한단어, PascalCase) / INTER-00-ListComponent	develop에 병합
issue	ISSUE-00(이슈번호)-이슈명(한단어, PascalCase) / ISSUE-11-FixTailwindClasses	develop에 병합
hotfix	HOTFIX-00(이슈번호)-hotfix명(한단어, PascalCase) / HOTFIX-911-OptimizeStateTransfer	main에 병합

Lint 규칙

주요 규칙

• var 는 사용하지 않습니다.

• 더 많은 정보는 https://standardjs.com/rules.html 를 참고하세요.

• 위 링크의 룰에서 예외인 경우입니다.

  • 세미 콜론 사용을 허용합니다.
  • 템플릿 리터럴 사용을 허용합니다.
  • Double Quote("") 사용만을 허용합니다.

변수 이름

• 클래스, 컴포넌트, 인터페이스, 타입: PascalCase
• 훅 함수: use를 접두어로 사용하는 camelCase (useAuth.ts)
• others: camelCase

파일 이름

• 컴포넌트, DTO, Entity 파일 : PascalCase
• 이미지, 영상 등 정적 파일, 라우팅 폴더: kebab-case
• [slug]와 같은 동적 라우팅 폴더: camelCase
• others: camelCase
• 긴 파일명은 역할과 컨텍스트를 명확하게 하기 위해 dot notation을 사용하여 구분한다.

ex) createTodo.usecase.ts ex2) todo.test.ts ex3) CreateTodo.dto.ts

html의 클래스 & 아이디 이름

• snake_case

스타일시트

• 거의 사용되지 않지만, globals.css, variables.css 형태로 사용합니다.

인터페이스 이름

• 모든 인터페이스 정의시에는 앞에 I를 붙인 형태의 이름으로 정의합니다. 예시: interface IFormRepository {}
• 이는 Domain계층의 repositories 폴더내의 파일명 작명규칙에도 적용됩니다. (infra의 repositories파일과 혼돈이 없기위함.) 예시: ISupabase.repository.ts

함수 타입

• 페이지 컴포넌트, 레이아웃 컴포넌트는 전부 function 함수를 사용합니다. (Next.js의 공식 컨벤션)
• others: 화살표 함수 사용

ex) export default function RootLayout() {} ex2) const Modal = () => {}

Import & Export 규칙

• 컴포넌트 폴더에서는 index.ts를 통한 재 export가 필요합니다. (일관성을 위함)

//index.ts
export * from "./Input";
export * from "./input.type";
export * from "./input.variants";

또한 1뎁스(../)를 넘어가는 요소를 import할때는 반드시 @ alias를 통해 import 합니다.

import { Input } from "@/app/components/input"; import { Input } from "./Input";

개별 파일에서 export default를 사용하지 않고 export const 와 같은 방식으로 export를 하셔야 index.ts에서 유효하게 재 export가 가능해집니다.

node & npm 버전 통일

• node : v22.15.1
• pnpm : v10.11.0

시맨틱 태그

• 각 페이지의 최상위 부모는 반드시 main태그를 사용합니다.
• section태그로 항목을 구분하고 section 태그내에는 반드시 하나라도 제목태그가 있어야합니다.
• 헤더의 메인로고는 h1과 a로 감싸서 사용합니다.