개발 초보자를 위한 GitHub Pull Request 만들고 코드 리뷰 받는 전체 흐름 실습 (브랜치 생성→커밋→PR→리뷰 반영)

개발을 시작하고 나서 가장 빨리 성장하는 순간은 “혼자 짠 코드”를 “다른 사람의 눈”으로 다시 보는 때입니다. 그런데 코드 리뷰를 받으려면 GitHub에서 Pull Request(PR)를 만들 줄 알아야 하죠. 오늘은 브랜치 만들기 → 커밋 → PR 생성 → 리뷰 반영(수정 커밋/리베이스) → 머지까지, 초보자도 그대로 따라 할 수 있게 한 번에 정리합니다.

준비물: 최소한 이것만 있으면 됩니다

• Git 설치, GitHub 계정
• 로컬에 클론된 저장소(Repository)
• 원격 기본 브랜치가 main이라고 가정(프로젝트에 따라 master일 수도 있어요)

1) 브랜치 생성: “작업은 무조건 가지치기부터”

기본 브랜치에서 바로 작업하면, 나중에 되돌리기 어렵고 충돌도 커집니다. 작업 단위마다 브랜치 1개가 기본이에요.

git switch main
git pull origin main
git switch -c feature/add-greeting

브랜치 이름은 보통 feature/, fix/, refactor/처럼 목적이 보이게 짓습니다. 나중에 PR 목록에서 한눈에 들어와요.

2) 코드 수정 예시: 작은 변경으로 실습해보기

예를 들어 app.js에 간단한 인사 함수를 추가해볼게요.

// app.js
export function greet(name) {
  return `Hello, ${name}!`;
}

가능하면 PR 하나에는 한 가지 목적만 담는 게 좋습니다. 리뷰어도 이해하기 쉽고, 승인도 빨라요.

3) 커밋: “의미 있는 단위로, 메시지는 명확하게”

변경 내용을 확인하고 커밋합니다.

git status
git add app.js
git commit -m "feat: add greet function"

커밋 메시지는 무엇을 왜 했는지가 핵심입니다. 예: fix: handle null name in greet, refactor: extract greeting formatter

4) 원격으로 푸시 & PR 만들기

브랜치를 원격에 올립니다.

git push -u origin feature/add-greeting

이후 GitHub에서 PR을 생성합니다. PR 제목/본문은 이렇게 쓰면 좋아요.

PR 제목 예시

• feat: greet 함수 추가

PR 본문 예시 템플릿

• 변경 사항: greet(name) 함수 추가
• 테스트: 로컬에서 간단 호출로 확인
• 참고: 기존 코드 영향 없음 리뷰어는 PR 본문만 읽고도 상황을 파악할 수 있어야 합니다.

5) 코드 리뷰 받기: 자주 나오는 피드백 패턴

리뷰에서 흔히 나오는 코멘트는 대략 이 3가지입니다.

1. 네이밍/가독성: 함수명, 변수명, 주석 위치
2. 예외 처리: null/빈 문자열, 타입 가정
3. 구조 개선: 중복 제거, 책임 분리 예를 들어 “name이 비어있으면 어떻게 돼요?”라는 리뷰를 받았다고 해볼게요.

6) 리뷰 반영: 수정 커밋으로 업데이트하기

요구사항에 맞게 코드를 고치고, 같은 브랜치에 커밋하면 PR에 자동으로 반영됩니다.

// app.js
export function greet(name) {
  const safeName = (name ?? "").trim();
  if (!safeName) return "Hello!";
  return `Hello, ${safeName}!`;
}

git add app.js
git commit -m "fix: handle empty name in greet"
git push

리뷰 코멘트에는 이렇게 답하면 좋아요.

• “말씀해주신 케이스 반영했습니다. 빈 문자열/공백은 기본 인사로 처리했습니다.” 중요: “반영했습니다”로 끝내지 말고, 어떻게 반영했는지를 한 줄 더 적으면 신뢰도가 확 올라갑니다.

7) 마지막 정리: 머지 전 체크리스트

PR이 승인되기 전에 아래를 점검하세요.

불필요한 파일(빌드 산출물, 로그) 커밋 안 됐나?

변경 범위가 PR 목적과 일치하나?

충돌(conflict) 가능성 없나? (필요 시 main 최신화)

main 최신화가 필요하면:

git switch main
git pull origin main
git switch feature/add-greeting
git merge main

충돌이 나면 파일을 열어 직접 정리한 뒤 커밋하고 푸시하면 됩니다.

8) 머지 이후: 브랜치 정리까지가 한 사이클

머지가 끝나면 브랜치를 정리합니다(선택이지만 권장).

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

원격 브랜치 삭제는 GitHub에서 버튼으로 지우거나, 명령어로도 가능합니다.

마무리: PR은 “코드 제출”이 아니라 “대화의 시작”

PR을 만들고 리뷰를 받는 과정은 단순히 승인을 받는 절차가 아니라, 팀의 코드 품질을 맞추고 개발 습관을 교정하는 훈련입니다. 처음엔 코멘트가 많아도 정상이에요. 중요한 건 방어하지 않고, 재현하고, 고치고, 설명하는 흐름을 익히는 것. 이 루틴이 몸에 붙으면 개발 실력이 정말 빠르게 올라갑니다.