Pull Request는 변경 사항을 합치기 전의 검토 요청이다
브랜치에서 작업을 끝냈다고 해서 바로 main에 합치는 것이 항상 좋은 방법은 아닙니다. 특히 여러 사람이 함께 작업한다면, 내가 바꾼 내용이 맞는지 확인하고 다른 사람의 의견을 듣는 과정이 필요합니다.
이때 사용하는 것이 Pull Request, 줄여서 PR입니다.
Pull Request는 말 그대로 "내 브랜치의 변경 사항을 main 브랜치에 가져가도 될까요?"라고 요청하는 절차입니다. GitHub 협업에서는 PR이 중심입니다. 코드를 확인하고, 의견을 남기고, 수정하고, 승인한 뒤 병합하는 공식 통로이기 때문입니다.
혼자 작업할 때도 PR은 유용합니다. 내가 무엇을 바꿨는지 한 번 더 확인할 수 있고, 나중에 변경 이력을 보기 쉽습니다.
GitHub Flow 한눈에 보기
GitHub Flow는 GitHub에서 많이 사용하는 단순한 협업 흐름입니다. 복잡한 규칙보다 "작게 나누어 작업하고, PR로 검토한 뒤 main에 합친다"는 원칙에 가깝습니다.
전체 순서는 다음과 같습니다.
main에서 새 브랜치를 만든다.새 브랜치에서 파일을 수정한다.
변경 사항을 커밋한다.
브랜치를 GitHub에 푸시한다.
Pull Request를 만든다.
리뷰를 받고 필요한 수정을 한다.
승인되면
main에 병합한다.작업이 끝난 브랜치를 삭제한다.
이 흐름의 핵심은 간단합니다.
main은 안정적인 상태로 유지하고, 새로운 작업은 브랜치에서 진행합니다. 그리고 브랜치 작업은 PR을 통해 검토한 뒤 main에 합칩니다.
Pull Request를 만들기 전 확인할 것
PR을 만들기 전에 먼저 내 브랜치가 GitHub에 올라가 있어야 합니다.
예를 들어 readme-update 브랜치에서 작업했다면 다음 순서로 진행합니다.
git status
git add README.md
git commit -m "Update README introduction"
git push -u origin readme-update여기서 중요한 점은 push입니다. 커밋은 내 컴퓨터의 로컬 저장소에 기록하는 작업이고, PR은 GitHub에서 만드는 작업입니다. 따라서 브랜치와 커밋이 GitHub 원격 저장소에 올라가 있어야 PR을 만들 수 있습니다.
푸시가 끝나면 GitHub 저장소 화면에 "Compare & pull request" 버튼이 나타나는 경우가 많습니다. 이 버튼을 누르면 바로 PR 작성 화면으로 이동할 수 있습니다.
버튼이 보이지 않아도 괜찮습니다. GitHub 저장소에서 Pull requests 탭으로 이동한 뒤 New pull request를 눌러 직접 만들 수 있습니다.
PR 제목과 설명은 무엇을 쓸까
PR을 만들 때 가장 많이 고민하는 부분이 제목과 설명입니다. 처음에는 길게 쓰려고 하지 않아도 됩니다. 다만 세 가지는 꼭 담는 것이 좋습니다.
무엇을 바꿨는가
왜 바꿨는가
어떻게 확인할 수 있는가
예를 들어 README 소개 문구를 수정한 PR이라면 다음처럼 작성할 수 있습니다.
제목: README 소개 문구 수정
## 변경 내용
- README에 프로젝트 소개 문장을 추가했습니다.
- 실행 방법 섹션의 문장을 조금 더 쉽게 다듬었습니다.
## 변경 이유
- 저장소에 처음 들어온 사람이 프로젝트 목적을 빠르게 이해할 수 있도록 하기 위해서입니다.
## 확인 방법
- GitHub에서 README 화면을 열어 소개 문구가 잘 보이는지 확인합니다.좋은 PR 설명은 리뷰어의 시간을 줄여 줍니다. 리뷰어가 코드를 처음부터 추측하지 않아도 되기 때문입니다.
반대로 다음과 같은 설명은 피하는 것이 좋습니다.
수정함이렇게만 쓰면 무엇을 왜 바꿨는지 알기 어렵습니다. 나중에 본인이 다시 봐도 기억이 나지 않을 수 있습니다.
Files changed에서 변경 내용 읽기
PR을 만들면 GitHub는 여러 탭을 보여 줍니다. 그중 가장 중요한 탭 중 하나가 Files changed입니다.
이곳에서는 이번 PR에서 어떤 파일이 어떻게 바뀌었는지 볼 수 있습니다. Git에서는 이런 변경 차이를 diff라고 부릅니다. diff는 이전 내용과 새 내용을 비교해서 보여 주는 화면입니다.
보통 다음처럼 표시됩니다.
빨간색 줄: 삭제된 내용
초록색 줄: 추가된 내용
회색 또는 일반 줄: 변경 전후를 이해하기 위한 주변 내용
예를 들어 README에서 다음 문장을 바꿨다고 해 보겠습니다.
- 이 저장소는 연습용입니다.
+ 이 저장소는 GitHub 사용법을 연습하기 위한 예제 프로젝트입니다.빨간 줄은 사라진 문장이고, 초록 줄은 새로 추가된 문장입니다. diff를 읽을 때는 "무슨 파일에서, 어떤 줄이, 어떤 의도로 바뀌었는가"를 확인하면 됩니다.
초보자는 처음에 diff 화면이 낯설 수 있습니다. 하지만 모든 줄을 완벽하게 해석하려고 하지 않아도 됩니다. 먼저 파일 이름을 보고, 그다음 초록색과 빨간색 줄을 비교하면 됩니다.
특히 PR을 병합하기 전에는 다음을 확인하세요.
의도하지 않은 파일이 포함되지 않았는가
삭제하면 안 되는 내용이 삭제되지 않았는가
오타나 불필요한 문장이 들어가지 않았는가
변경 내용이 PR 설명과 일치하는가
혼자 작업하더라도 이 확인 과정은 매우 중요합니다. 실수를 main에 넣기 전에 발견할 수 있기 때문입니다.
리뷰어, 코멘트, 승인 이해하기
PR은 단순히 병합 버튼을 누르기 위한 화면이 아닙니다. 협업을 위한 대화 공간이기도 합니다.
PR에서 다른 사람에게 검토를 요청할 수 있습니다. 이 사람을 리뷰어라고 합니다. 리뷰어는 변경 내용을 보고 의견을 남깁니다.
리뷰 과정에서 자주 만나는 표현은 다음과 같습니다.
Comment: 단순 의견이나 질문입니다.
Request changes: 수정이 필요하다는 요청입니다.
Approve: 이 변경 사항을 병합해도 좋다는 승인입니다.
예를 들어 리뷰어가 Files changed 화면에서 특정 줄에 이런 코멘트를 남길 수 있습니다.
이 문장은 조금 더 짧게 바꾸면 좋겠습니다.그러면 작성자는 브랜치에서 파일을 수정하고 다시 커밋한 뒤 푸시하면 됩니다.
git add README.md
git commit -m "Refine README wording"
git push이미 열린 PR에 연결된 브랜치로 푸시하면, PR에도 자동으로 새 커밋이 반영됩니다. PR을 새로 만들 필요는 없습니다.
리뷰어가 변경 사항을 확인하고 문제가 없다고 판단하면 Approve를 남길 수 있습니다. 팀에 따라 승인이 있어야 병합할 수 있도록 설정하기도 합니다.
중요한 점은 리뷰를 비난으로 받아들이지 않는 것입니다. PR 리뷰는 사람을 평가하는 과정이 아니라, 변경 사항을 더 안전하게 만들기 위한 과정입니다.
병합과 브랜치 삭제
리뷰가 끝났고 문제가 없다면 PR을 main에 병합할 수 있습니다. GitHub PR 화면에는 보통 Merge pull request 버튼이 있습니다.
이 버튼을 누르면 readme-update 브랜치의 변경 사항이 main 브랜치에 합쳐집니다.
병합이 끝난 뒤에는 작업 브랜치를 삭제해도 됩니다. 이미 변경 내용은 main에 들어갔기 때문입니다. GitHub는 병합 후 Delete branch 버튼을 보여 줍니다.
브랜치를 삭제하는 것은 작업 이력을 지우는 것이 아닙니다. 커밋과 PR 기록은 남아 있습니다. 삭제하는 것은 더 이상 필요 없는 작업용 브랜치 이름을 정리하는 것입니다.
로컬 저장소에서도 필요 없다면 브랜치를 삭제할 수 있습니다.
git switch main
git pull origin main
git branch -d readme-update여기서 git pull origin main은 GitHub의 최신 main 내용을 내 컴퓨터로 가져오는 명령입니다. PR이 GitHub에서 병합되었으므로, 로컬 main도 최신 상태로 맞춰 주는 것이 좋습니다.
실전 예시: README 수정 PR 만들기
이제 전체 흐름을 하나의 예시로 정리해 보겠습니다. 목표는 readme-update 브랜치에서 README를 수정하고 PR로 main에 병합하는 것입니다.
먼저 main에서 새 브랜치를 만듭니다.
git switch main
git pull origin main
git switch -c readme-updateREADME.md 파일을 열고 소개 문장을 추가합니다.
# github-remote-practice
GitHub 사용법을 연습하기 위한 예제 저장소입니다.변경 내용을 확인합니다.
git status
git diff문제가 없다면 커밋합니다.
git add README.md
git commit -m "Add README introduction"브랜치를 GitHub에 올립니다.
git push -u origin readme-update이제 GitHub 저장소로 이동합니다. Compare & pull request 버튼을 누르고 PR 제목과 설명을 작성합니다.
제목: README 소개 문구 추가
## 변경 내용
- README에 저장소 소개 문장을 추가했습니다.
## 변경 이유
- 저장소의 목적을 처음 보는 사람도 이해할 수 있도록 하기 위해서입니다.
## 확인 방법
- README 화면에서 소개 문장이 표시되는지 확인합니다.PR을 만든 뒤 Files changed 탭을 눌러 변경된 줄을 확인합니다. 의도한 README 문장만 추가되었다면 좋습니다.
리뷰어가 있다면 리뷰를 요청합니다. 혼자 연습 중이라면 스스로 리뷰어가 되었다고 생각하고 변경 내용을 다시 읽어 봅니다.
문제가 없다면 Merge pull request를 눌러 병합합니다. 그다음 Delete branch로 작업 브랜치를 정리합니다.
마지막으로 내 컴퓨터의 main도 최신 상태로 맞춥니다.
git switch main
git pull origin main
git branch -d readme-update이 과정을 마치면 GitHub Flow를 한 번 완주한 것입니다.
이번 장의 핵심 정리
Pull Request는 브랜치의 변경 사항을 main에 합치기 전 검토하는 절차입니다. GitHub 협업에서는 PR을 중심으로 코드 확인, 의견 교환, 수정, 승인, 병합이 이루어집니다.
GitHub Flow는 단순합니다. 브랜치를 만들고, 변경하고, 커밋하고, 푸시한 뒤 PR을 엽니다. 리뷰를 거쳐 문제가 없으면 main에 병합하고 브랜치를 삭제합니다.
PR 설명에는 무엇을 바꿨는지, 왜 바꿨는지, 어떻게 확인할 수 있는지를 적으면 됩니다. Files changed에서는 빨간 줄과 초록 줄을 보며 삭제된 내용과 추가된 내용을 확인합니다.
이 흐름에 익숙해지면 GitHub는 단순히 코드를 올리는 공간이 아니라, 안전하게 협업하는 작업 공간이 됩니다.
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.