GitHub Pull Request(PR) 입문 — 코드 리뷰 받는 법, 처음부터 따라하기

Git으로 브랜치를 만들고 코드를 push하는 건 해봤는데 "PR을 만들어주세요"라는 말에 멈춘 적 있나요? PR은 어렵지 않아요. "내가 작업한 걸 합쳐도 될까요?" 하고 요청하는 것뿐입니다.

이 글에서 PR 만드는 법부터 코드 리뷰, Merge까지 처음부터 따라해볼게요.

이 글은 이런 분을 위해 쓴 거예요
1) Git 브랜치가 뭔지는 알고 git add/commit/push를 해본 적 있는 분
2) PR(Pull Request)이라는 걸 처음 만들어보려는 분
3) 팀 프로젝트나 오픈소스에 기여하기 전에 PR 흐름을 미리 익히고 싶은 분

Git 브랜치가 아직 어렵다면 Git 브랜치 전략을 먼저 읽어보세요.

Git 브랜치 전략, 혼자 개발해도 이건 알아야 합니다

---

목차

1. PR이 뭔데?
2. 왜 PR을 쓸까?
3. PR 만드는 법 — 실전 흐름
4. 좋은 PR 작성법
5. 코드 리뷰 받고 수정하기
6. Merge하고 브랜치 삭제
7. PR 관련 용어 정리

---

✳️ PR이 뭔데?

PR은 Pull Request의 줄임말이에요. 한 마디로 "내가 작업한 걸 합쳐도 될까요?" 하고 요청하는 거예요.

좀 더 구체적으로 설명하면 아래와 같습니다:

1. main 브랜치에서 새 브랜치를 만들어서 작업해요
2. 작업이 끝나면 GitHub에 push해요
3. "이 변경사항을 main 브랜치에 합쳐주세요"라고 요청(Request)을 보내요
4. 팀원이 코드를 확인하고(리뷰) 괜찮으면 합쳐요(Merge)

이게 PR의 전체 흐름이에요. 생각보다 간단하죠?

이름이 Pull Request인 이유는? 내가 작업한 브랜치의 변경사항을 메인 브랜치로 "당겨와(Pull) 달라"고 요청(Request)하는 거라서 그래요.

✳️ 왜 PR을 쓸까?

"그냥 main 브랜치에 바로 push하면 안 되나?" 싶을 수 있어요. 물론 혼자 작업하면 그렇게 해도 되긴 하는데 PR을 쓰면 이런 점이 좋아요.

📌 팀으로 일할 때

• 다른 사람이 내 코드를 확인해줘요 (코드 리뷰). 실수를 미리 잡을 수 있어요.
• "누가, 왜, 뭘 바꿨는지"가 PR 단위로 깔끔하게 기록돼요.
• main 브랜치에 검증되지 않은 코드가 들어가는 걸 막을 수 있어요.

📌 혼자 할 때도 유용해요

• 변경 이력이 PR 단위로 정리돼서 나중에 찾기 쉬워요.
• "이 기능 언제 추가했더라?" → 해당 PR만 보면 돼요.
• 실수로 main에 직접 push하는 걸 방지할 수 있어요.
• 포트폴리오에서 "나 이런 작업 했어요"를 PR 링크로 보여줄 수 있어요.

반응형

✳️ PR 만드는 법 — 실전 흐름

실제로 PR을 만들어볼게요. 터미널과 GitHub 웹사이트를 번갈아 쓰게 돼요.

📌 Step 1: 새 브랜치 만들고 이동

# main 브랜치에서 시작
git checkout main

# 최신 상태로 업데이트
git pull origin main

# 새 브랜치 만들고 이동
git checkout -b feature/add-login-page

브랜치 이름은 작업 내용을 알 수 있게 지어요. feature/기능명, fix/버그명, docs/문서명 같은 형태가 일반적이에요.

📌 Step 2: 작업하고 커밋

# 파일 수정 후 스테이징
git add login.html login.css

# 커밋 메시지 작성
git commit -m "feat: 로그인 페이지 HTML/CSS 추가"

커밋은 여러 번 해도 돼요. 작업 단위로 나눠서 커밋하면 나중에 리뷰하기도 편하고 문제가 생겼을 때 되돌리기도 쉬워요.

📌 Step 3: GitHub에 push

git push origin feature/add-login-page

처음 push하면 GitHub에 해당 브랜치가 생겨요.

📌 Step 4: GitHub에서 PR 생성

push하고 나서 GitHub 저장소 페이지에 가면 상단에 노란색 배너가 떠요.

"Compare & pull request" 버튼을 클릭하면 PR 생성 화면이 나와요.

여기서 채워야 할 것:

• base 브랜치: 합칠 대상 (보통 dev 또는 main)
• compare 브랜치: 내가 작업한 브랜치 (feature/add-login-page)
• 제목: 이 PR이 뭘 하는지 한 줄로
• 설명: 변경 내용, 이유, 확인할 점 등

다 작성했으면 "Create pull request" 버튼을 누르면 돼요.

✳️ 좋은 PR 작성법

PR은 그냥 만들면 끝이 아니에요. 리뷰하는 사람이 쉽게 이해할 수 있도록 잘 작성하는 게 중요해요.

📌 제목은 간결하게

❌ 로그인 관련 작업
❌ 수정함
✅ feat: 로그인 페이지 UI 구현
✅ fix: 로그인 시 비밀번호 검증 오류 수정

접두어를 붙이면 어떤 종류의 변경인지 한눈에 보여요:

• feat: — 새 기능
• fix: — 버그 수정
• docs: — 문서 수정
• refactor: — 코드 리팩토링
• style: — 코드 스타일 변경 (동작 변경 없음)

📌 설명은 "왜"를 중심으로

## 변경 사항
- 로그인 페이지 HTML/CSS 추가
- 이메일/비밀번호 입력 폼 구현
- 반응형 레이아웃 적용

## 이유
- 회원가입 기능에 앞서 로그인 UI가 먼저 필요함

## 확인 방법
- login.html을 브라우저로 열면 로그인 폼이 보임
- 모바일 크기로 줄여도 레이아웃이 깨지지 않음

리뷰하는 사람 입장에서는 "뭘 바꿨는지"보다 "왜 바꿨는지"가 더 중요해요. 코드를 보면 뭘 바꿨는지는 알 수 있지만 왜 바꿨는지는 설명이 없으면 모르거든요.

📌 변경 범위는 작게

한 PR에 너무 많은 변경을 넣으면 리뷰하기 어려워요. "로그인 페이지 UI + 회원가입 API + 데이터베이스 설계"를 하나의 PR에 넣는 것보다 각각 따로 PR을 만드는 게 좋아요.

✳️ 코드 리뷰 받고 수정하기

PR을 만들면 팀원이 코드를 확인하고 코멘트를 남겨요. 이게 코드 리뷰예요.

📌 리뷰 코멘트 확인하기

PR 페이지에서 "Files changed" 탭을 보면 변경된 코드와 함께 리뷰어가 남긴 코멘트를 볼 수 있어요.

코멘트는 보통 이런 종류가 있어요:

• 질문: "이 부분은 왜 이렇게 했나요?"
• 제안: "이렇게 바꾸면 더 좋을 것 같아요"
• 승인: "좋아요! 문제없습니다" (Approve)
• 변경 요청: "이 부분은 수정이 필요해요" (Request changes)

📌 수정하고 다시 push하기

리뷰에서 수정 요청이 오면 같은 브랜치에서 코드를 수정하고 다시 push하면 돼요.

# 리뷰 반영해서 코드 수정
# ... 파일 수정 ...

# 스테이징 + 커밋
git add login.css
git commit -m "fix: 리뷰 반영 — 모바일 패딩 값 수정"

# 같은 브랜치에 push
git push origin feature/add-login-page

새로 push하면 PR에 자동으로 반영돼요. 새 PR을 만들 필요 없어요. 리뷰어가 다시 확인하고 괜찮으면 승인(Approve)해줘요.

✳️ Merge하고 브랜치 삭제

리뷰어가 승인하면 드디어 Merge할 수 있어요.

📌 Merge 방법

PR 페이지 하단에 초록색 "Merge pull request" 버튼이 있어요. 클릭하면 내 작업이 main 브랜치에 합쳐져요.

Merge 방식은 3가지가 있는데 처음에는 기본값(Create a merge commit)을 쓰면 돼요:

방식	설명
Create a merge commit	병합 커밋을 하나 만들어요 (기본값, 처음엔 이걸로)
Squash and merge	여러 커밋을 하나로 합쳐서 병합해요
Rebase and merge	커밋을 그대로 유지하면서 병합해요

📌 브랜치 삭제

Merge가 끝나면 작업 브랜치는 더 이상 필요 없어요. GitHub에서 "Delete branch" 버튼을 눌러 삭제하고 로컬에서도 정리해요.

# main으로 돌아가기
git checkout main

# 최신 상태 반영
git pull origin main

# 로컬 브랜치 삭제
git branch -d feature/add-login-page

이제 한 사이클이 끝났어요. 다음 작업할 때는 다시 Step 1부터 새 브랜치를 만들면 돼요.

✳️ PR 관련 용어 정리

용어	의미
Pull Request (PR)	내 브랜치의 변경사항을 합쳐달라고 요청하는 것
Reviewer	PR을 확인하고 리뷰해주는 사람
Approve	리뷰어가 "괜찮습니다, 합쳐도 돼요"라고 승인하는 것
Request Changes	리뷰어가 "수정이 필요해요"라고 변경을 요청하는 것
Merge	PR의 변경사항을 대상 브랜치에 합치는 것
Conflict	같은 파일의 같은 부분을 여러 사람이 수정해서 충돌이 난 상태
Draft PR	아직 작업 중인 PR. 리뷰 요청 전에 먼저 올려두고 싶을 때 사용
Base branch	PR이 합쳐질 대상 브랜치 (보통 main)
Compare branch	내가 작업한 브랜치
Assignee	이 PR의 담당자
Label	PR에 붙이는 태그 (bug, enhancement, documentation 등)

---

이전 글: [개발/개발환경] - GitHub 처음 쓰는 사람을 위한 가이드 - push, pull, clone

관련 글: [개발/개발환경] - Git 브랜치 전략, 혼자 개발해도 이건 알아야 합니다

---

수정해야 하는 부분이 있거나 궁금한 점 있으면 댓글 남겨주시고 도움이 되셨다면 공감 부탁드려요!