이 문서는 협업을 위한 코딩 규칙, 커밋 규칙, 브랜치 전략을 명확히 정의합니다.
-
변수명은 camelCase, 컴포넌트명은 PascalCase
-
모든 컴포넌트는 하나의 파일에 하나의 컴포넌트만 작성합니다.
-
컴포넌트 파일명과 컴포넌트 이름은 반드시 동일해야 하며, PascalCase로 작성합니다.
- 예:
Button.js,LoginForm.js
- 예:
-
컴포넌트 내부 로직은 최대한 간결하게 유지하고, 복잡한 로직은 커스텀 훅(
hooks)으로 분리합니다. -
스타일링은 반드시 Styled Components를 사용하며, 스타일 코드는 별도의
.styled.js파일로 분리합니다.- 예:
Button.styled.js
- 예:
-
반복되는 상태 관리 및 로직은 커스텀 훅(
hooks)으로 모듈화하여 재사용성을 높입니다.
- Hooks는 항상 최상위 레벨에서만 호출합니다. (조건문, 반복문, 중첩된 함수 내에서 호출 금지)
- Hooks는 React 컴포넌트 또는 커스텀 훅 내에서만 호출합니다. 일반 JavaScript 함수에서는 호출하지 않습니다.
- 컴포넌트는 항상 입력(props, state, context)에 따라 동일한 결과를 반환해야 합니다. (idempotent)
- JSX에 전달된 값(props 등)은 불변성을 유지합니다. JSX에 전달된 값은 이후 변경하지 않습니다.
본 프로젝트는 GitHub Flow 전략을 기반으로 간단하고 명확한 브랜치 전략을 사용합니다.
main브랜치는 항상 배포 가능한 최신 안정 버전을 유지합니다.- 새로운 기능 개발 또는 버그 수정 시 별도의 브랜치를 생성하여 작업합니다.
- 작업 완료 후 PR(Pull Request)을 통해 코드 리뷰를 받고 병합합니다.
브랜치 이름은 다음 규칙을 따릅니다:
| 브랜치 유형 | 설명 | 예시 |
|---|---|---|
| main | 배포 가능한 안정적인 코드가 존재하는 메인 브랜치 | main |
| develop | 개발자들이 작업한 기능(feature branch)을 병합하여 통합하는 개발 브랜치 | develop |
| feature | 새로운 기능 개발 시 생성하는 브랜치 | feat/login-page, feat/webrtc-video-call |
| fix | 버그 수정 시 생성하는 브랜치 | fix/login-error |
| hotfix | 긴급하게 수정해야 하는 버그 발생 시 main에서 분기하여 작업 후 main과 develop에 병합 | hotfix/login-error |
# 최신 코드 받아오기
git checkout develop
git pull origin develop
# 새 기능(feature) 개발 시작
git checkout -b feat/webrtc-video-call
# 작업 후 커밋
git add .
git commit -m "feat(webrtc): implement video call UI and logic"
# 원격 저장소에 푸시 및 PR 생성
git push origin feat/webrtc-video-call
# GitHub에서 Pull Request(PR) 생성 → 팀 리뷰 후 develop 브랜치에 병합효율적인 협업과 프로젝트 관리를 위해 다음과 같은 커밋 규칙을 따르기
커밋 메시지는 다음 구조를 따릅니다:
<type>(<scope>): <subject>
<body>
<footer>
커밋의 유형을 나타내며, 다음 중 하나를 선택합니다:
feat: 새로운 기능 추가fix: 버그 수정docs: 문서 수정style: 코드 형식 변경 (코드 로직에 영향을 주지 않는 변경)refactor: 코드 리팩토링test: 테스트 코드 추가 또는 수정chore: 빌드 프로세스 또는 보조 도구 변경perf: 성능 개선ci: CI 설정 파일 및 스크립트 변경revert: 이전 커밋으로 되돌리기
변경이 영향을 미치는 범위를 나타냅니다. 예: auth, navbar, api
- 변경 사항을 간결하게 설명합니다.
- 명령문 형태로 작성합니다. (예: "변경", "추가", "수정" 등으로 시작)
- 첫 글자는 소문자로 작성합니다.
- 끝에 마침표(
.)를 사용하지 않습니다.
- 변경 이유와 변경 내용을 자세히 설명합니다.
- 여러 줄로 작성 가능합니다.
- Breaking Changes: 호환성을 깨뜨리는 변경사항 명시
- Closed Issues: 해결된 이슈 번호 명시 (예:
Closes #123, #456)
feat(auth): 소셜 로그인 기능 추가
- Google과 Kakao 소셜 로그인 구현
- 유저 프로필 정보 연동 및 DB 저장 로직 추가
Closes #123, #456
fix(api): 회원 인증 토큰 만료 버그 해결
- 토큰 갱신 로직 수정
- 잘못된 예외 처리 로직 개선
Closes #789
docs(readme): 프로젝트 설치 가이드 업데이트
docs(api): 엔드포인트 명세서 수정
refactor(auth): 로그인 로직 모듈화
- 중복된 코드를 제거하고 함수 재사용성을 높임
test(user): 회원가입 단위 테스트 추가
- Edge case를 고려한 테스트 케이스 작성
- 논리적 단위로 커밋 나누기: 하나의 커밋에는 하나의 논리적 변경사항만 포함합니다.
- 자주 커밋하기: 작업 내용을 잃지 않도록 작은 단위로 커밋합니다.
- 커밋 전 코드 리뷰하기:
git diff명령어를 사용하여 변경사항을 다시 한 번 확인합니다. - 테스트 통과 확인: 커밋하기 전 모든 테스트가 통과하는지 확인합니다.
- 브랜치 전략 준수: 팀에서 정한 브랜치 전략(예: Git Flow, GitHub Flow)을 따릅니다.
- 영어로 커밋 메시지 작성하기: 국제적인 협업과 오픈소스 기여를 고려합니다.
- 현재형으로 작성하기: "Added feature"가 아닌 "Add feature"로 작성합니다.
- 50자 이내로 간결하게 작성하기: 커밋 메시지의 가독성을 높입니다.
- 관련 이슈 번호 참조하기: 커밋 메시지에 관련 이슈 번호를 포함합니다 (예:
Closes #123).
- 코드 포맷팅 확인
- 린트 검사 통과
- 테스트 코드 실행
- 불필요한 콘솔/주석 제거