Pull Request가 뭔가요?

Pull Request(PR)는 "내가 작성한 코드를 프로젝트에 합쳐주세요"라고 요청하는 것입니다. 혼자 작업할 때는 직접 main 브랜치에 푸시하지만, 팀 프로젝트에서는 PR을 통해 다른 사람이 코드를 검토한 후 합칩니다.

왜 PR을 사용할까?

• 코드 품질: 다른 사람이 검토하여 버그를 미리 발견
• 지식 공유: 코드 리뷰를 통해 서로 배움
• 기록: 왜 이렇게 작성했는지 토론 기록 남음
• 안전: main 브랜치를 보호하고 안정성 유지

PR 작업 흐름

1. Fork (다른 사람 프로젝트) 또는 Branch 생성 (팀 프로젝트)
   ↓
2. 코드 작성 및 커밋
   ↓
3. Push to origin
   ↓
4. Pull Request 생성
   ↓
5. 코드 리뷰
   ↓
6. 수정 반영
   ↓
7. Merge (병합)

실전 예제: 팀 프로젝트에서 PR 만들기

1단계: 새 브랜치 생성

# 최신 코드 가져오기
git checkout main
git pull origin main

# 새 브랜치 생성
git checkout -b feature/add-login-button

# 브랜치 이름 규칙:
# - feature/기능명: 새 기능
# - fix/버그명: 버그 수정
# - docs/내용: 문서 수정
# - refactor/내용: 리팩토링

2단계: 코드 작성

# 파일 수정 후
git add .
git commit -m "Add login button to header

- Add styled button component
- Connect click handler
- Update responsive layout"

# 커밋 메시지 팁:
# 첫 줄: 50자 이내, 명령형
# 빈 줄
# 상세 설명: 무엇을, 왜 변경했는지

3단계: Push

# 브랜치를 원격에 푸시
git push origin feature/add-login-button

# 처음 푸시할 때는 -u 옵션
git push -u origin feature/add-login-button

4단계: GitHub에서 PR 생성

1. GitHub 저장소 페이지로 이동
2. "Pull requests" 탭 클릭
3. "New pull request" 클릭
4. base: main ← compare: feature/add-login-button 선택
5. "Create pull request" 클릭

5단계: PR 설명 작성

## 변경 사항
로그인 버튼을 헤더에 추가했습니다.

## 작업 내용
- [ ] 로그인 버튼 컴포넌트 생성
- [ ] 헤더에 버튼 추가
- [ ] 클릭 이벤트 핸들러 연결
- [ ] 반응형 디자인 적용

## 스크린샷
![Button Screenshot](screenshot.png)

## 테스트
- 데스크톱 Chrome에서 테스트 완료
- 모바일 Safari에서 테스트 완료

## 관련 이슈
Closes #123

## 리뷰어
@teamleader @designer

좋은 PR 만들기

1. 작은 단위로

한 번에 너무 많은 변경사항을 넣지 마세요. 리뷰하는 사람이 부담스러워합니다.

• ✅ 좋은 예: "로그인 버튼 추가" (파일 3-5개, 줄 변경 100-200)
• ❌ 나쁜 예: "로그인 기능 전체 구현" (파일 20개, 줄 변경 1000+)

2. 명확한 제목과 설명

❌ 나쁜 제목: "수정"
❌ 나쁜 제목: "버그 고침"
✅ 좋은 제목: "Fix: 로그인 버튼 클릭 시 404 에러 수정"
✅ 좋은 제목: "Add: 사용자 프로필 페이지 구현"

3. 스크린샷/GIF 첨부

UI 변경사항이 있다면 꼭 시각적으로 보여주세요.

4. 테스트 결과 공유

## 테스트 완료
- [x] Chrome (Windows)
- [x] Safari (Mac)
- [x] Mobile Chrome
- [ ] Firefox (테스트 필요)

코드 리뷰 받기

리뷰 요청하기

# PR에서 Reviewers 선택
# 팀원 멘션
@username 코드 리뷰 부탁드립니다!

# 특정 부분에 대한 의견 요청
이 부분 더 좋은 방법이 있을까요?
```javascript
// 현재 코드
```

리뷰 받을 때 마음가짐

• ✅ 리뷰는 코드에 대한 것, 나에 대한 것이 아님
• ✅ 배울 기회로 생각하기
• ✅ 방어적이 되지 않기
• ✅ 왜 그렇게 했는지 설명하되, 더 나은 방법 열린 마음으로 수용

피드백에 응답하기

✅ 좋은 응답:
"좋은 지적 감사합니다! 수정했습니다."
"그 방법도 고려했는데, [이유]로 현재 방식을 선택했습니다. 어떻게 생각하시나요?"

❌ 나쁜 응답:
"이게 최선이에요"
"그냥 이렇게 하면 안 되나요?"
(무응답)

Conflict 해결하기

여러 사람이 같은 파일을 수정하면 충돌(conflict)이 발생합니다.

Conflict 발생 시나리오

# 상황:
# 1. 내가 feature 브랜치에서 작업 중
# 2. 다른 팀원이 main에 변경사항 merge
# 3. 내 PR이 conflict 발생

# 해결 방법:
git checkout main
git pull origin main              # 최신 코드 가져오기
git checkout feature/my-branch
git merge main                    # main을 내 브랜치에 합치기

# Conflict 발생!
# VS Code에서 파일 열면 표시됨:
<<<<<<< HEAD
내 코드
=======
다른 사람 코드
>>>>>>> main

# 수정 후
git add .
git commit -m "Resolve merge conflict"
git push

Conflict 예방하기

• 자주 main 브랜치의 변경사항 가져오기
• PR은 빨리 올리고 빨리 merge하기
• 팀원과 작업 영역 조율하기

코드 리뷰하기

리뷰어의 역할

• 버그 찾기
• 더 나은 방법 제안
• 코드 스타일 확인
• 학습 기회 제공
• 좋은 코드 칭찬하기!

리뷰 코멘트 작성법

❌ 나쁜 코멘트:
"이거 왜 이렇게 했어요?"
"이거 틀렸어요"

✅ 좋은 코멘트:
"이 부분에서 null 체크를 추가하면 어떨까요?"
"map 대신 forEach를 사용하면 더 명확할 것 같습니다. 어떻게 생각하시나요?"
"이 함수 정말 깔끔하네요! 👍"

리뷰 태그 활용

[MUST] 반드시 수정해야 함
[SHOULD] 수정 권장
[NITS] 사소한 것
[QUESTION] 질문
[PRAISE] 칭찬

예시:
[MUST] null 체크가 필요합니다.
[NITS] 변수명을 더 명확하게 하면 좋을 것 같습니다.
[PRAISE] 이 로직 정말 깔끔하네요!

PR Merge 후

# 브랜치 삭제 (선택)
git checkout main
git branch -d feature/my-branch        # 로컬
git push origin --delete feature/my-branch  # 원격

# 또는 GitHub에서 "Delete branch" 버튼 클릭

Draft PR 활용

아직 완성되지 않았지만 일단 피드백을 받고 싶을 때:

1. PR 생성 시 "Create draft pull request" 선택
2. WIP (Work In Progress) 표시
3. 초기 피드백 받기
4. 완성 후 "Ready for review" 전환

GitHub PR 템플릿

저장소에 .github/pull_request_template.md 파일 생성:

## 변경 사항


## 변경 이유


## 체크리스트
- [ ] 테스트 추가
- [ ] 문서 업데이트
- [ ] 코드 스타일 확인
- [ ] 직접 테스트 완료

## 스크린샷 (필요시)

## 리뷰 포인트

자주 묻는 질문

Q. PR을 잘못 올렸어요!

A. 괜찮습니다! PR은 Close할 수 있고, 새로 만들 수 있습니다.

Q. 리뷰 받고 수정하는 중에 또 커밋해도 되나요?

A. 네! 같은 브랜치에 커밋하면 PR에 자동으로 반영됩니다.

Q. 리뷰어가 응답을 안 해요

A. 정중하게 리마인더: "시간 나실 때 리뷰 부탁드립니다 🙏"

"좋은 PR과 코드 리뷰는 팀의 코드 품질을 높이고, 모두가 함께 성장하는 기회를 만듭니다."

PR은 처음에는 어색하지만, 익숙해지면 자연스러운 협업 방식이 됩니다. 작은 프로젝트부터 시작해서 PR 문화에 익숙해지세요!