Git 기초 #6 GitHub와 첫 Pull Request

1편부터 5편까지 로컬 저장소에서 커밋을 쌓고, 브랜치를 나누고 머지하고, 원격 저장소와 동기화하고, 실수를 되돌리는 방법까지 갖췄습니다. 이제 마지막 조각이 남았습니다. 혼자 쓰는 Git과 팀에서 쓰는 Git의 가장 큰 차이, 바로 Pull Request입니다. 브랜치의 변경을 리뷰를 거쳐 합류시키는 이 절차는 현대 개발 협업의 표준입니다.

총 6편으로 구성됩니다.

• #1 Git이란 — 스냅샷 모델과 세 영역
• #2 add·commit·status — 스테이징 영역의 의미
• #3 브랜치와 머지 — fast-forward와 3-way
• #4 원격 저장소 — clone·fetch·pull·push와 origin의 정체
• #5 되돌리기 — restore·reset·revert 구분
• #6 GitHub와 첫 Pull Request ← 이번 글

이번 글은 GitHub에 저장소를 만들어 로컬 저장소를 연결하고, 첫 Pull Request를 열어 머지하고 정리하는 데까지 전체 흐름을 순서대로 따라가겠습니다.

Pull Request란 무엇인가 #

Pull Request는 이름 그대로 요청입니다. “제 브랜치의 변경을 이 브랜치로 가져가(pull) 주세요"라는 요청이고, 줄여서 PR이라고 부릅니다. 하지만 실무에서 PR의 가치는 머지 요청 자체보다 그 위에서 벌어지는 일에 있습니다. 동료가 변경된 코드를 줄 단위로 리뷰하고, 코멘트로 대화하고, 수정을 반영한 뒤에 합류시키는 리뷰의 공간이 PR입니다.

한 가지 구분해 둘 점이 있습니다. Pull Request는 Git 자체의 기능이 아닙니다. git pull-request라는 명령은 존재하지 않습니다. PR은 GitHub라는 호스팅 서비스가 Git 위에 얹은 기능입니다. 그래서 GitLab에서는 같은 것을 Merge Request라고 부릅니다. 이름은 달라도 구조는 같습니다. 브랜치, 커밋, 푸시는 Git의 영역이고, 리뷰와 머지 버튼은 호스팅 서비스의 영역입니다.

GitHub에 저장소 만들기 #

4편에서는 이미 존재하는 원격 저장소를 clone하는 흐름을 다뤘습니다. 이번에는 반대 방향입니다. 로컬에 이미 있는 저장소를 GitHub에 새로 올립니다.

GitHub에 로그인해 New repository 버튼으로 새 저장소를 만듭니다. 저장소 이름만 정하고, README와 .gitignore 추가 옵션은 모두 비워 둡니다. 로컬에 이미 커밋 히스토리가 있으므로 원격은 빈 상태여야 충돌 없이 올라갑니다.

저장소를 만들면 GitHub가 주소를 알려 줍니다. 이 주소를 origin이라는 이름으로 등록하고 푸시합니다.

git remote add origin https://github.com/<계정>/<저장소>.git
git push -u origin main

-u 옵션은 4편에서 다룬 대로 로컬 main과 원격 main을 추적 관계로 묶는 설정입니다. 한 번 설정해 두면 이후에는 git push만으로 충분합니다.

첫 Pull Request — 브랜치에서 머지까지 #

이제 실제 작업 흐름을 처음부터 끝까지 따라가겠습니다. 시나리오는 간단합니다. 인사말 기능을 브랜치에서 만들어 PR로 합류시킵니다.

먼저 브랜치를 만들어 작업하고 커밋합니다.

git switch -c feature/greeting
# greeting.py 작성
git add greeting.py
git commit -m "feat: 인사말 함수 추가"

이 브랜치를 원격에 올립니다. 처음 올리는 브랜치이므로 여기서도 -u를 붙입니다.

git push -u origin feature/greeting

푸시 직후 GitHub 저장소 페이지를 열면 방금 올린 브랜치에 대해 Compare & pull request 버튼이 나타납니다. 이 버튼을 누르면 PR 작성 화면으로 이동합니다.

작성 화면 상단에는 방향이 표시됩니다. base가 변경을 받아들일 브랜치이고, compare가 변경을 보내는 브랜치입니다. 지금은 base가 main, compare가 feature/greeting입니다. 이 방향을 확인하는 습관을 들여 두면 나중에 여러 브랜치를 오갈 때 실수를 줄일 수 있습니다.

제목과 설명을 작성합니다. 요령은 두 가지입니다. 제목에는 무엇을 했는지를, 설명에는 왜 했는지를 씁니다. 리뷰어는 코드 diff에서 무엇이 바뀌었는지는 볼 수 있지만, 왜 바꿨는지는 설명 없이 알 수 없습니다. 배경과 의도를 한두 문단으로 적는 것만으로 리뷰의 질이 달라집니다.

리뷰 코멘트와 추가 커밋 #

PR을 열면 동료가 코드를 리뷰합니다. 수정 요청 코멘트를 받았다면 어떻게 반영해야 할까요? 답은 간단합니다. 같은 브랜치에서 수정하고 커밋해서 다시 푸시하면 됩니다.

# feature/greeting 브랜치에서 코드 수정
git add greeting.py
git commit -m "fix: 리뷰 반영 - 빈 이름 입력 처리"
git push

PR은 브랜치를 가리키고 있으므로, 그 브랜치에 새 커밋을 푸시하면 열려 있는 PR에 자동으로 반영됩니다. PR을 닫고 다시 열 필요가 없습니다. 리뷰 코멘트, 수정 커밋, 재리뷰가 이 방식으로 반복되다가 승인이 나면 머지 단계로 넘어갑니다.

머지 버튼 세 가지 #

GitHub의 머지 버튼에는 세 가지 방식이 있습니다.

Merge commit은 3편에서 다룬 3-way 머지와 같은 동작입니다. Squash and merge는 “오타 수정”, “리뷰 반영” 같은 자잘한 커밋이 많을 때 main 히스토리를 깔끔하게 유지하는 데 유용합니다. Rebase and merge는 일직선 히스토리를 선호하는 팀이 사용합니다.

기초 단계의 권장 기준은 단순합니다. 팀의 관례를 따르는 것입니다. 이미 운영 중인 저장소라면 기존 PR들이 어떤 방식으로 머지되었는지 확인하고 같은 방식을 쓰면 됩니다. 개인 프로젝트라면 어느 방식이든 무방하지만, 커밋이 지저분해지기 쉬운 초반에는 Squash and merge가 부담이 적습니다.

머지 후 정리 #

머지가 끝난 브랜치는 역할을 다했으므로 정리합니다. GitHub가 머지 직후 보여 주는 Delete branch 버튼으로 원격 브랜치를 삭제하고, 로컬도 정리합니다.

git switch main
git pull
git branch -d feature/greeting

main으로 돌아와 머지 결과를 pull로 받아 오면, 로컬 main에도 방금 머지된 변경이 반영됩니다. 그다음 git branch -d로 로컬 브랜치를 삭제합니다. 3편에서 다룬 대로 머지가 끝난 브랜치의 삭제는 커밋을 잃지 않는 안전한 작업입니다.

여기까지가 한 사이클입니다. 브랜치 생성부터 커밋, 푸시, PR, 리뷰, 머지, 정리까지 한 바퀴를 돌았고, 실무의 하루는 이 사이클의 반복입니다.

시리즈 전체 요약 #

여섯 편의 핵심을 한 줄씩 정리합니다.

• #1 Git은 변경 이력을 스냅샷으로 기록하며, 작업 디렉터리, 스테이징 영역, 저장소라는 세 영역으로 동작합니다.
• #2 add는 스냅샷 후보를 고르는 일이고, commit은 고른 것을 기록으로 확정하는 일입니다.
• #3 브랜치는 커밋을 가리키는 가벼운 포인터이며, 머지에는 fast-forward와 3-way 두 방식이 있습니다.
• #4 origin은 원격 저장소 주소의 별명이고, pull은 fetch와 merge의 조합입니다.
• #5 되돌리기는 커밋 전 restore, 푸시 전 amend와 reset, 푸시 후 revert로 구분합니다.
• #6 Pull Request는 브랜치의 변경을 리뷰를 거쳐 합류시키는 협업의 표준 절차입니다.

마무리 #

이 시리즈는 Git을 처음 배우는 데 필요한 최소한의 지도를 그리는 것이 목표였습니다. 여기까지 따라왔다면 혼자서든 팀에서든 Git으로 작업을 기록하고 공유하는 기본기는 갖춘 셈입니다.

다음 단계는 실무의 상황들입니다. 팀 규모에 맞는 브랜치 전략, rebase와 merge의 선택 기준, interactive rebase로 커밋 정리하기, 충돌을 구조적으로 이해하고 해결하기 같은 주제를 다루는 실무 워크플로우 시리즈를 준비하고 있습니다. 이상으로 Git 기초 시리즈를 마칩니다.