### PR 및 커밋 컨벤션 안내
**Conventional Commits**와 **PR 관리**는 협업 프로젝트에서 코드 변경 사항을 명확하고 일관되게 기록하는 중요한 도구입니다. 이를 통해 코드 변경 내역을 쉽게 파악하고, 릴리즈 및 버전 관리를 자동화할 수 있습니다. 아래는 PR 및 커밋 작성 시 참고할 수 있는 상세한 가이드입니다.
---
#### **1. Conventional Commits 사양**
Conventional Commits는 커밋 메시지를 일관성 있게 작성하도록 도와주는 규칙입니다. 이 규칙을 따르면 자동으로 변경 로그를 생성하거나, 버전 관리를 더욱 간편하게 할 수 있습니다. 기본적인 형식은 다음과 같습니다.
<type>(<scope>): <description>
- **type**: 커밋의 성격을 나타냅니다. 주로 사용하는 타입은 아래와 같습니다:
- **feat**: 새로운 기능 추가
- **fix**: 버그 수정
- **docs**: 문서 관련 변경
- **style**: 코드 포맷팅, 세미콜론 누락 등 기능에 영향을 주지 않는 변경
- **refactor**: 코드 리팩토링 (기능 변경 없음)
- **test**: 테스트 추가나 수정
- **chore**: 빌드 관련 설정이나 패키지 매니저 설정 등
- **scope**(선택 사항): 커밋의 영향을 받는 코드의 영역을 명시합니다. 예를 들어, `user`, `api`와 같은 특정 모듈을 명시할 수 있습니다.
- **description**: 간단하고 명확한 커밋의 내용을 작성합니다. **현재형**으로 작성하는 것이 일반적입니다.
**예시**:
feat(user): 사용자 로그인 기능 추가 fix(api): 인증 헤더 누락 문제 해결
---
#### **2. 커밋 메시지 작성 시 주의사항**
- **커밋 메시지는 짧고 명확하게 작성**해야 합니다. 첫 번째 줄은 커밋의 핵심을 50자 이내로 요약하고, 이후 필요하다면 한 줄 띄운 후 상세한 설명을 추가할 수 있습니다.
- **문장의 첫 단어는 대문자로**, 그리고 명령형으로 작성하는 것이 일반적입니다. 예: "Add", "Fix", "Remove".
- **Breaking Changes**가 있을 경우, 커밋 메시지에 `!`를 사용하여 이를 강조합니다. 예: `feat!: remove deprecated API`.
- 구체적인 변경 사항을 설명하는 **본문(body)**과 추가적인 정보(이슈 번호, 리뷰어 등)를 적는 **푸터(footer)**도 필요할 경우 추가할 수 있습니다.
---
#### **3. PR 제목 및 설명 작성 가이드**
PR(풀 리퀘스트)의 제목과 설명도 커밋 메시지와 마찬가지로 명확해야 하며, **Conventional Commits** 형식을 따르는 것이 권장됩니다. 특히, **Squash Merge**를 사용하는 경우, PR 제목이 머지 후 단일 커밋 메시지가 되기 때문에 더욱 중요합니다.
- **PR 제목**: 커밋과 마찬가지로 명령형으로 작성합니다. 예를 들어, "Add user authentication"과 같이 작성합니다.
- **PR 설명**:
- **변경된 이유**: 왜 이 변경이 필요한지 설명합니다.
- **변경된 주요 사항**: 어떤 부분이 변경되었는지 구체적으로 기술합니다.
- **테스트 방법**: 변경 사항이 어떻게 테스트되었는지 설명합니다. 가능한 한 상세하게 작성하여 리뷰어가 테스트를 재현할 수 있도록 합니다.
**예시**:
PR 제목: feat(user): 사용자 로그인 기능 추가
PR 설명: 이 PR은 사용자 로그인 기능을 추가합니다.
테스트 방법:
/login 페이지에서 이메일과 비밀번호를 입력하여 로그인을 시도합니다.
---
#### **4. PR 리뷰 및 머지 과정**
PR 작성 후 팀원들이 리뷰를 하게 되면, 리뷰어는 변경된 내용을 확인하고 피드백을 제공합니다. PR은 여러 번 수정될 수 있으며, 최종 승인이 나면 머지되게 됩니다. 구글과 같은 대형 기술 기업에서는 **Squash Merge**를 권장합니다. 이 방식은 모든 커밋을 하나로 합쳐 단일 커밋으로 병합하므로, 커밋 히스토리가 깔끔하게 유지됩니다 [oai_citation:2,GitHub - googleapis/release-please: generate release PRs based on the conventionalcommits.org spec](<https://github.com/googleapis/release-please>) [oai_citation:1,Conventional Commit In Pull Requests · Actions · GitHub Marketplace · GitHub](<https://github.com/marketplace/actions/conventional-commit-in-pull-requests>).
---
#### **5. 마무리**
효과적인 커밋 메시지 작성과 PR 관리는 프로젝트의 유지 보수성과 협업 효율성을 높여줍니다. 구글과 같은 기업에서 사용하는 **Conventional Commits** 사양을 따르면, 릴리즈 관리와 버전 업데이트가 자동화되어 생산성이 향상됩니다. 이러한 컨벤션을 준수하여 커밋과 PR을 작성하면 팀 내 소통이 원활해지고, 코드 품질을 향상시킬 수 있습니다.
---
이 가이드는 구글과 같은 대형 기술 기업에서 채택한 컨벤션을 바탕으로 작성되었습니다.
Conventional Commits와 PR 관리는 협업 프로젝트에서 코드 변경 사항을 명확하고 일관되게 기록하는 중요한 도구입니다. 이를 통해 코드 변경 내역을 쉽게 파악하고, 릴리즈 및 버전 관리를 자동화할 수 있습니다. 아래는 PR 및 커밋 작성 시 참고할 수 있는 상세한 가이드입니다.
Conventional Commits는 커밋 메시지를 일관성 있게 작성하도록 도와주는 규칙입니다. 이 규칙을 따르면 자동으로 변경 로그를 생성하거나, 버전 관리를 더욱 간편하게 할 수 있습니다. 기본적인 형식은 다음과 같습니다.
<type>(<scope>): <description>
user, api와 같은 특정 모듈을 명시할 수 있습니다.예시:
feat(user): 사용자 로그인 기능 추가
fix(api): 인증 헤더 누락 문제 해결
!를 사용하여 이를 강조합니다. 예: feat!: remove deprecated API.