개발 초보자를 위한 GitHub Pull Request 만들기: 브랜치 생성부터 머지까지 한 번에

Pull Request가 뭐고, 왜 필요한가요?

Pull Request는 “제가 만든 변경사항을 이 브랜치에 합쳐주세요”라고 요청하는 기능입니다. PR을 쓰면 다음이 좋아요.

• 변경 내용이 한눈에 비교됨(추가/삭제 라인 확인)
• 리뷰 코멘트를 코드 옆에서 바로 주고받음
• 실수로 메인 브랜치를 망가뜨릴 위험이 줄어듦

시작 전 준비: 기본 용어 3개만 잡고 가기

• main/master: 보통 배포 가능한 안정 브랜치
• feature 브랜치: 내가 작업할 전용 브랜치(예: feature/login)
• upstream / origin: 원본 저장소 / 내 포크 저장소를 쓰는 경우 구분됨(팀마다 다름)

1) 브랜치 만들기(가장 중요한 습관)

먼저 최신 main을 가져오고, 그 기준으로 새 브랜치를 만듭니다.

git checkout main
git pull origin main
git checkout -b feature/login

브랜치 이름은 보통 feature/기능, fix/버그, refactor/정리처럼 목적이 드러나게 씁니다. 브랜치명만 봐도 무슨 작업인지 보이면 협업이 훨씬 편해요.

2) 코드 수정 후 커밋: “작게, 의미 있게”

작업을 하고 변경 파일을 확인합니다.

git status
git diff

스테이징 후 커밋:

git add .
git commit -m "feat: 로그인 폼 유효성 검사 추가"

커밋 메시지는 팀 규칙이 없다면 최소한 무엇을 했는지(동사+대상)가 보이게 작성해 주세요. 예: fix: 비밀번호 길이 검증 오류 수정

3) 원격 브랜치에 푸시하고 PR 만들기

처음 푸시라면 upstream 설정까지 같이:

git push -u origin feature/login

이제 GitHub에서 Compare & pull request 버튼이 보이거나, Pull requests 탭에서 새 PR을 만들 수 있어요.

PR 작성 팁(리뷰가 잘 달리는 글)

• 제목: 작업 목적이 드러나게 예) 로그인 입력값 검증 추가

• 본문(예시 템플릿):

## 변경 내용
- 로그인 폼에 이메일/비밀번호 유효성 검사 추가
- 에러 메시지 UI 표시

## 테스트 방법
1) 로그인 페이지 접속
2) 이메일 형식이 아닐 때 에러 메시지 확인
3) 비밀번호 8자 미만 입력 시 에러 확인

## 참고
- 관련 이슈: #12

여기서 핵심은 리뷰어가 재현할 수 있게 “테스트 방법”을 적는 것입니다. 이 한 줄이 리뷰 속도를 크게 올려줘요.

4) 코드 리뷰 받기: 코멘트 대응 요령

리뷰 코멘트가 달리면 당황하지 말고, 먼저 의도를 확인하세요.

• 단순 수정 요청: 바로 반영 후 커밋
• 논의가 필요한 의견: 왜 그렇게 했는지 설명하고 대안 제시 수정 후에는 같은 브랜치에 커밋해서 다시 푸시하면 PR에 자동으로 반영됩니다.

git add .
git commit -m "refactor: 유효성 검사 함수 분리"
git push

리뷰 코멘트는 GitHub에서 Resolve conversation으로 정리해두면, “이 PR은 정리되었구나”가 한눈에 보여요.

5) 충돌(conflict) 없이 머지하려면: 최신 main 반영

리뷰 받는 동안 main이 업데이트되면 내 브랜치도 최신으로 맞추는 게 좋습니다.

방법 A) merge로 반영(초보자에게 안전)

git checkout feature/login
git fetch origin
git merge origin/main

충돌이 나면 Git이 표시한 파일을 열고, 충돌 표식(<<<<<<)을 정리한 뒤 커밋합니다.

방법 B) rebase(히스토리를 깔끔하게, 팀 합의 필요)

팀에서 rebase를 쓰는 문화라면 진행하되, 익숙하지 않다면 먼저 물어보는 게 안전합니다.

6) 머지 방식 선택: Squash / Merge / Rebase

PR이 승인되면 머지 버튼을 누르게 됩니다. 저장소 설정에 따라 옵션이 보일 수 있어요.

• Squash and merge: 커밋이 여러 개라도 1개로 합쳐 머지(많이 사용)
• Create a merge commit: 머지 커밋을 남김(흐름이 명확)
• Rebase and merge: 선형 히스토리(팀 규칙 중요) 초보자라면 팀에서 자주 쓰는 방식을 그대로 따르는 게 정답입니다.

마무리: 초보자가 자주 하는 실수 3가지

1. main에서 바로 작업하기 → 반드시 feature 브랜치 사용
2. PR에 설명 없이 파일만 던지기 → 변경 내용/테스트 방법 적기
3. 리뷰 코멘트를 개인 공격처럼 받아들이기 → 코드 품질을 같이 올리는 과정 이 흐름만 익히면, GitHub PR은 “무서운 절차”가 아니라 안전한 협업 루틴이 됩니다. 다음 PR에서는 제목과 테스트 방법만이라도 깔끔하게 써보세요. 리뷰가 훨씬 부드럽게 돌아갈 거예요.