728x90
반응형
PR 작성 컨벤션
PR 작성에 대한 공식 표준은 없지만 흔히 사용되는 컨벤션은 존재합니다.
PR 제목
- Conventional Commits 스타일을 따르는 경우가 많습니다.
feat: Support dark mode in user settings
PR 본문
- 커밋 메시지 포맷 (conventional commit) 을 강제하지 않으며, 오히려 자연어 중심으로 작성하도록 유도합니다.
- 주로 Summary, Changes, Testing, Related Issues 를 작성합니다.
- Summary: 이 PR의 목적과 핵심 변경 사항을 간단히 설명합니다.
- Changes: 구체적으로 어떤 작업을 했는지 나열합니다.
- Testing: 변경 사항이 어떻게 테스트되었는지 설명하며 테스트 방법과 테스트 결과를 간략히 공유합니다.
- Related Issues: 연관된 이슈나 작업을 링크로 첨부합니다.
### Summary
Fixed an issue where the pagination in the user list was displaying incorrect page numbers.
### Changes
- Updated the pagination logic in `UserListView`
- Added unit tests to cover edge cases for pagination
- Refactored the `paginate` helper function for better readability
### Testing
- Verified pagination manually with large datasets
- All existing tests pass
### Related Issues
Resolves #101
- 저장소 관리자가 프로젝트에 .github/PULL_REQUEST_TEMPLATE.md 파일을 추가하여 PR 본문 작성 시 사용할 수 있는 템플릿을 제공하기도 합니다.
### Summary
<!-- Briefly describe the purpose of this PR -->
N/A
### Changes
<!-- List major changes made in this PR -->
N/A
### Testing
<!-- Explain how this was tested -->
N/A
### Related Issues
<!-- Link to related issues -->
N/A
.github/ 는 GitHub 의 설정 파일들을 관리하기 위한 전용 디렉터리입니다. PULL_REQUEST_TEMPLATE.md 파일을 필수로 해당 디렉터리에 넣어야 하는것은 아니지만 권장 위치입니다. GitHub 설정 파일을 코드와 분리하여 관리할 수 있어 프로젝트 구조가 깔끔해지기 때문에 많은 오픈소스 프로젝트가 이 구조를 따릅니다.
제목 레벨의 # 개수는 팀 내 컨벤션에 따라 적절하게 사용합니다.
PR 리뷰
PR 리뷰에 대한 공식 표준은 없지만 흔히 사용되는 컨벤션은 존재합니다.
PR 검증
PR 을 승인하기 전에 코드가 잘 작동하는지 검증하는 것은 리뷰어의 중요한 역할입니다. 보통 아래의 순서로 검증을 진행합니다.
- 자동화된 테스트 확인 (1차 검증)
- CI/CD 파이프라인 검사
- PR 에는 보통 자동화된 테스트가 연결되어 있어 PR 생성 시나 업데이트 시 테스트가 실행됩니다.
- 테스트 통과 여부를 확인하여 코드가 기존 기능을 깨트리지 않는지 검증합니다.
- ex. GitHub Actions, Jenkins 등
- 커버리지 검사
- 테스트 커버리지가 충분한지 확인합니다.
- CI/CD 파이프라인 검사
- 코드 리뷰 (2차 검증)
- 리뷰어가 직접 코드 변경 내용을 확인하여 논리적 오류, 코드 스타일, 설계 문제를 검증합니다.
- 리뷰어가 변경된 코드의 품질과 유지 보수성을 평가합니다.
- 로컬 테스트 (3차 검증)
- 코드 변경 사항을 로컬로 체크아웃 (브랜치 가져오기) 하여 직접 실행 및 테스트합니다.
- PR 에 테스트 방법이 명시되어 있으면 이를 따라 검증합니다.
- 리뷰어에게 로컬 테스트가 필수는 아니지만 변경사항이 복잡하거나 민감한 경우 로컬에서 직접 실행하여 검증하는 것이 좋습니다.
로컬 테스트 진행 시 임시 브랜치 생성 혹은 Docker 나 VM 같은 별도의 테스트 환경을 사용하여 원본 브랜치를 보호할 수 있도록 주의합니다.
대부분의 경우 자동화된 테스트 + 코드 리뷰가 일반적이지만, 복잡하거나 위험도가 높은 변경사항의 경우 로컬 테스트를 병행하거나 QA 팀에서 추가로 검증을 진행하기도 합니다.
PR 리뷰 코멘트
PR 리뷰 코멘트 작성에 대한 명확한 표준은 없지만 Google 이나 Microsoft 와 같은 대규모 조직에서는 리뷰 가이드라인을 공식적으로 제공하기도 합니다. 주로 코드 리뷰를 명확하고, 건설적이며, 구체적으로 작성해야 함을 강조하고 있습니다.
728x90
반응형
'Dev > VCS' 카테고리의 다른 글
Git 브랜치 관리 (2) | 2025.04.25 |
---|---|
Git 브랜치 이름 변경 (2) | 2025.04.24 |
Git 태그 (2) | 2024.12.31 |
Git 브랜치 삭제 (3) | 2024.12.29 |
Git rebase, squash (2) | 2024.12.27 |