앞 레슨에서는 내가 직접 git merge로 브랜치를 합쳤습니다. 혼자라면 그것도 괜찮습니다. 하지만 팀으로 일할 때는 '바로 합치기' 대신 '합쳐도 될지 먼저 물어보고 검토받기'를 합니다. 이 공식 요청서가 바로 풀 리퀘스트(Pull Request), 줄여서 PR입니다.
PR = '합쳐 주세요' 요청서
PR은 GitHub에게 "제 feature 브랜치의 작업을 main에 합쳐(pull) 주세요"라고 내는 정식 요청서입니다. 이름이 'Pull' Request인 이유죠. 이 요청서에는 '무엇을 왜 바꿨는지' 설명을 적고, 팀원은 여기서 코드를 한 줄씩 살펴보며 의견을 답니다. 문서를 팀에 공유하고 '검토 후 승인' 받는 결재 과정과 똑같습니다.
풀 리퀘스트(PR)의 흐름
- feature 브랜치 작업 + 커밋
- PR 열기 feature/login을 push하고 GitHub에 PR 생성 (합쳐주세요)
- 리뷰 팀원이 코멘트·승인. 수정 요청 시 다시 커밋·push하면 PR에 자동 반영
- 병합(merge) 승인 후 main에 반영
브랜치를 올리고 PR을 열면, 리뷰를 거쳐 승인된 뒤에야 main에 병합됩니다.
PR 만들기: push → gh pr create
PR을 만들려면 먼저 내 브랜치를 GitHub에 올려야(push) 합니다. 검토할 코드가 원격에 있어야 하니까요. 그다음 GitHub 웹사이트에서 버튼으로 만들 수도 있지만, 터미널에서 gh pr create 한 줄이면 더 빠릅니다.
브랜치 올리고 PR 만들기
# 1. 작업한 feature 브랜치를 원격에 올리기 (처음엔 -u)
git push -u origin feature/login
# 2. PR 생성 (제목과 설명을 입력하는 대화형 화면이 뜸)
gh pr create
# 제목·본문을 바로 지정하고 싶다면:
gh pr create --title "로그인 기능 추가" --body "이메일·비밀번호 로그인 폼과 유효성 검사를 구현했습니다."
# 만든 PR을 브라우저로 열어 확인
gh pr view --web좋은 PR 설명 쓰는 법
- 무엇을(What): 이 PR이 어떤 변경을 담고 있는지 요약합니다.
- 왜(Why): 이 변경이 필요한 이유나 해결하는 문제를 적습니다.
- 어떻게 확인(How to test): 리뷰어가 동작을 확인하는 방법을 알려 줍니다. 예: '로그인 페이지에서 빈 값으로 제출하면 에러 메시지가 뜨는지 확인'
왜 굳이 PR로 협업하나요?
- 품질: 합치기 전에 다른 눈으로 검토받아 버그를 미리 잡습니다.
- 기록: '왜 이렇게 바꿨는지'가 PR에 대화로 남아, 나중에 이유를 추적할 수 있습니다.
- 안전: main에 바로 넣지 않으므로, 문제가 있으면 병합 전에 막을 수 있습니다.
혼자 하는 프로젝트라도 PR을 쓰면 좋습니다. PR을 열어 두고 '셀프 리뷰', 즉 스스로 변경된 코드(diff)를 처음부터 끝까지 다시 읽어 보세요. 작성할 때는 안 보이던 실수가 리뷰어의 눈으로 볼 때 놀랍도록 잘 보입니다.
PR을 올린 뒤 리뷰어가 수정을 요청하면, 새 PR을 또 만들 필요가 없습니다. 같은 브랜치에서 코드를 고쳐 커밋하고 git push만 하면, 그 변경이 기존 PR에 자동으로 반영됩니다. PR은 '브랜치와 연결된 살아 있는 요청서'라는 점을 기억하세요.
PR로 협업하는 흐름을 익혔습니다. 그런데 여러 사람이 같은 파일을 고치다 보면 가끔 '충돌'이 납니다. 다음 레슨에서 충돌이 무엇이고 어떻게 푸는지, 그리고 애초에 올리면 안 되는 파일을 막는 법을 배웁니다.