Dev/VCS

PR 작성과 리뷰

dragonhyeon 2024. 12. 31. 22:41
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. 자동화된 테스트 확인 (1차 검증)
    • CI/CD 파이프라인 검사
      • PR 에는 보통 자동화된 테스트가 연결되어 있어 PR 생성 시나 업데이트 시 테스트가 실행됩니다.
      • 테스트 통과 여부를 확인하여 코드가 기존 기능을 깨트리지 않는지 검증합니다.
      • ex. GitHub Actions, Jenkins 등
    • 커버리지 검사
      • 테스트 커버리지가 충분한지 확인합니다.
  2. 코드 리뷰 (2차 검증)
    • 리뷰어가 직접 코드 변경 내용을 확인하여 논리적 오류, 코드 스타일, 설계 문제를 검증합니다.
    • 리뷰어가 변경된 코드의 품질과 유지 보수성을 평가합니다.
  3. 로컬 테스트 (3차 검증)
    • 코드 변경 사항을 로컬로 체크아웃 (브랜치 가져오기) 하여 직접 실행 및 테스트합니다.
    • PR 에 테스트 방법이 명시되어 있으면 이를 따라 검증합니다.
    • 리뷰어에게 로컬 테스트가 필수는 아니지만 변경사항이 복잡하거나 민감한 경우 로컬에서 직접 실행하여 검증하는 것이 좋습니다.
로컬 테스트 진행 시 임시 브랜치 생성 혹은 Docker 나 VM 같은 별도의 테스트 환경을 사용하여 원본 브랜치를 보호할 수 있도록 주의합니다.

 

대부분의 경우 자동화된 테스트 + 코드 리뷰가 일반적이지만, 복잡하거나 위험도가 높은 변경사항의 경우 로컬 테스트를 병행하거나 QA 팀에서 추가로 검증을 진행하기도 합니다.

PR 리뷰 코멘트

PR 리뷰 코멘트 작성에 대한 명확한 표준은 없지만 Google 이나 Microsoft 와 같은 대규모 조직에서는 리뷰 가이드라인을 공식적으로 제공하기도 합니다. 주로 코드 리뷰를 명확하고, 건설적이며, 구체적으로 작성해야 함을 강조하고 있습니다.

728x90
반응형
저작자표시 비영리 변경금지 (새창열림)