CS학습4 min read
Pull Request: 브랜치의 변경을 리뷰하고 병합하기 위한 협업 단위
Pull Request(PR)는 작업 브랜치의 변경 사항을 대상 브랜치에 병합해 달라고 요청하는 협업 기능이다. Git 자체의 명령이 아니라 GitHub, GitLab 등 호스팅 플랫폼이 제공하며, 코드 리뷰와 자동 검사(CI)가 이루어지는 공간이 된다. 이 글에서는 PR의 개념, 동작 흐름, 명령어 예제, 실무 규칙을 정리한다.
By 송민성
1. 개념
Pull Request(PR)는 "내 브랜치의 변경을 대상 브랜치(보통 main)에 가져가(pull) 달라"고 요청하는 기능이다. GitLab에서는 같은 기능을 Merge Request(MR)라고 부른다.
- PR은 Git의 핵심 명령이 아니다.
git pull과는 다른 것이다. Git 저장소를 호스팅하는 플랫폼이 Git 위에 얹어 제공하는 기능이다. - PR 하나는 기준 브랜치(base), 비교 브랜치(compare/head), 두 브랜치 사이의 커밋 목록과 차이(diff), 토론(코멘트), 검사 결과(CI) 로 구성된다.
2. 왜 사용하는가
- 코드 리뷰(Code Review): 병합 전에 다른 팀원이 변경을 읽고 의견을 남긴다.
- 자동 검증: 테스트, 린트, 빌드를 CI(지속적 통합, Continuous Integration)가 PR마다 실행한다.
- 기록: 변경 이유와 논의 과정이 남아, 나중에 "왜 이렇게 바꿨는가"를 추적할 수 있다.
- main 보호: 브랜치 보호 규칙(Branch Protection)과 결합하면 승인과 검사를 통과한 변경만 병합할 수 있다.
3. 동작 원리
일반적인 흐름은 다음과 같다.
main에서 작업 브랜치를 만든다.- 브랜치에서 커밋한다.
- 원격 저장소(remote)로 브랜치를 푸시(push)한다.
- 플랫폼에서 PR을 연다. base는
main, compare는 작업 브랜치다. - 리뷰어가 코멘트하고, 작성자는 같은 브랜치에 커밋을 추가해 반영한다. 푸시하면 PR에 자동으로 반영된다.
- CI 통과와 승인을 얻으면 병합한다.
병합 방식은 보통 세 가지다.
| 방식 | 결과 |
|---|---|
| Merge commit | 병합 커밋을 만들어 두 브랜치의 이력을 모두 보존 |
| Squash and merge | PR의 커밋들을 하나로 합쳐 base에 추가 |
| Rebase and merge | PR의 커밋들을 base 위에 재배치해 선형 이력 유지 |
포크(fork) 기반 협업에서는 내 포크의 브랜치에서 원본 저장소의 브랜치로 PR을 연다.
4. 코드 예제
GitHub CLI(gh)를 사용한 흐름이다. gh가 설치되어 있고 gh auth login이 끝났다고 가정한다.
shell
# 1. 최신 main에서 작업 브랜치 생성
git switch main
git pull origin main
git switch -c feature/add-login-validation
# 2. 작업 후 커밋
git add .
git commit -m "feat: 로그인 입력값 검증 추가"
# 3. 원격에 푸시 (upstream 설정 포함)
git push -u origin feature/add-login-validation
# 4. PR 생성
gh pr create \
--base main \
--title "feat: 로그인 입력값 검증 추가" \
--body "이메일 형식과 비밀번호 길이를 검증합니다."
# 5. 리뷰 반영: 같은 브랜치에 커밋하고 푸시하면 PR이 갱신됨
git add .
git commit -m "fix: 리뷰 반영 - 에러 메시지 수정"
git push
# 6. 상태 확인 및 병합 (squash 방식)
gh pr status
gh pr merge --squash --delete-branch병합 후 로컬 정리는 다음과 같다.
shell
git switch main
git pull origin main
git branch -d feature/add-login-validationPR 본문은 템플릿으로 통일하면 좋다. .github/pull_request_template.md 파일을 두면 PR 생성 시 자동으로 채워진다.
shell
mkdir -p .github
cat > .github/pull_request_template.md << 'EOF'
## 변경 내용
-
## 변경 이유
-
## 테스트 방법
-
## 체크리스트
- [ ] 테스트 추가/수정
- [ ] 문서 갱신
EOF5. 시간 복잡도 또는 성능 특성
PR은 알고리즘이 아니므로 시간복잡도 대신 운영 특성을 본다.
- 리뷰 비용은 변경 크기에 따라 커진다. 변경 줄 수가 늘수록 리뷰어가 놓치는 문제가 많아지는 경향이 있어, 작은 PR이 권장된다.
- 오래 열려 있는 PR은
main과 차이가 벌어져 충돌(conflict) 가능성이 높아진다. - CI 실행 시간은 PR의 피드백 속도에 직접 영향을 준다.
6. 실무 사용 사례
- 기능 개발: 기능 단위 브랜치로 PR을 열고 팀 리뷰 후 병합한다.
- 핫픽스(Hotfix): 긴급 수정도 PR로 올리되 리뷰 범위를 좁혀 빠르게 처리한다.
- 오픈소스 기여: 저장소를 포크하고, 브랜치를 만들어 원본에 PR을 보낸다.
- 초안(Draft) PR: 작업 중인 상태를 미리 공유해 방향을 조기에 확인한다.
gh pr create --draft로 만들 수 있다. - 브랜치 보호 규칙: 최소 승인 수, 필수 CI 통과, 직접 푸시 금지를 설정한다.
7. 주의할 점
- PR을 너무 크게 만들지 않는다. 하나의 PR은 하나의 목적만 담는다.
- 무관한 변경을 섞지 않는다. 포맷팅 일괄 변경과 기능 변경을 한 PR에 넣으면 리뷰가 어려워진다.
- 충돌은 작성자가 해결한다.
main을 브랜치로 병합(merge)하거나 리베이스(rebase)한다. 리베이스 후에는git push --force-with-lease가 필요하며, 다른 사람이 같은 브랜치를 쓰고 있다면 조율해야 한다. - 비밀 정보를 커밋하지 않는다. PR에 올라간 API 키는 커밋을 지워도 이력에 남을 수 있으므로 키를 폐기(revoke)해야 한다.
- 설명 없는 PR을 올리지 않는다. 변경 이유와 테스트 방법이 없으면 리뷰어가 맥락을 추측해야 한다.
- 병합 방식(Squash, Rebase 등)은 팀 규칙에 맞춰 통일한다.
8. 핵심 정리
- PR은 Git 명령이 아니라 호스팅 플랫폼의 협업 기능이며, 브랜치 간 변경을 리뷰하고 병합하는 단위다.
- 흐름은 브랜치 생성 → 커밋 → 푸시 → PR 생성 → 리뷰·CI → 병합이다.
- 리뷰 중 같은 브랜치에 푸시하면 PR이 자동으로 갱신된다.
- 병합 방식은 Merge commit, Squash, Rebase 세 가지이며 팀 규칙에 맞춰 선택한다.
- 작고 목적이 분명한 PR, 충실한 설명, 브랜치 보호 규칙이 좋은 PR 문화의 기본이다.