Git Pull Request 리뷰에서 Request Changes 사용하기

Git을 사용하는 팀에서는 기능 개발 브랜치의 변경 사항을 다른 브랜치에 반영하기 전에 Pull Request(PR)를 만들어 코드 리뷰를 진행하는 경우가 많습니다.

리뷰 과정에서 수정이 필요한 부분을 발견하면 GitHub나 Gitea 같은 Git 호스팅 서비스에서 Request Changes를 사용할 수 있습니다.

다만 먼저 구분해야 할 점이 있습니다.

Request Changes와 Pull Request는 Git 명령 자체가 아닙니다. Git은 브랜치, 커밋, merge, push 같은 버전 관리 기능을 제공하고, Pull Request와 코드 리뷰 기능은 GitHub, Gitea, GitLab, Bitbucket 같은 Git 기반 협업 서비스에서 제공합니다.

이 글에서는 특정 제품에 한정하지 않고 Git을 이용한 일반적인 Pull Request 협업 흐름을 기준으로 Request Changes의 의미와 수정 방법을 설명합니다.

---

Request Changes 동작 방식

Pull Request를 리뷰한 결과 현재 변경 사항을 그대로 승인하기 어렵고 수정이 필요하다면 리뷰어는 Request Changes를 선택할 수 있습니다.

예를 들어 다음과 같은 브랜치 구조가 있습니다.

feature/order-cancel
        ↓
       dev

feature/order-cancel에서 개발한 내용을 dev에 반영하기 위해 Pull Request를 생성합니다.

리뷰어가 다음 코드를 확인합니다.

public void cancelOrder(Order order) {
    order.cancel();
    repository.deleteAll();
}

주문 하나를 취소하는 처리에서 전체 주문 데이터가 삭제될 가능성이 있으므로 merge 전에 반드시 수정해야 하는 문제입니다.

이런 경우 리뷰어는 해당 코드에 의견을 남기고 Request Changes로 리뷰를 제출할 수 있습니다.

전체 흐름은 다음과 같습니다.

Pull Request 생성
        ↓
코드 리뷰
        ↓
수정이 필요한 문제 발견
        ↓
Request Changes
        ↓
Pull Request는 유지
        ↓
작성자가 코드 수정
        ↓
같은 브랜치에 commit / push
        ↓
기존 Pull Request 갱신
        ↓
재검토

Request Changes를 선택했다고 해서 Pull Request가 자동으로 닫히거나 삭제되는 것은 아닙니다.

일반적으로 다음 의미로 이해하면 됩니다.

현재 변경 사항에는 수정이 필요합니다.
수정된 내용을 다시 확인한 뒤 승인하겠습니다.

Request Changes 후에는 기존 Pull Request를 닫고 새로 만들 필요가 없습니다. 수정한 내용을 기존 Pull Request의 소스 브랜치에 push하면 해당 Pull Request에서 계속 리뷰할 수 있습니다.

---

수정 코드 반영 방법

다음과 같은 Pull Request가 있다고 가정하겠습니다.

source branch : feature/order-cancel
target branch : dev

리뷰어가 Request Changes를 남겼다면 작성자는 feature/order-cancel 브랜치에서 코드를 수정합니다.

브랜치로 이동합니다.

git checkout feature/order-cancel

git switch를 사용하는 경우에는 다음과 같이 할 수도 있습니다.

git switch feature/order-cancel

코드를 수정한 뒤 변경 사항을 확인합니다.

git status
git diff

수정한 파일을 staging 합니다.

git add .

커밋합니다.

git commit -m "fix: 리뷰 요청 사항 반영"

원격 저장소의 같은 브랜치에 push합니다.

git push origin feature/order-cancel

Git 관점에서는 이 작업으로 원격 feature/order-cancel 브랜치에 새로운 커밋이 추가됩니다.

feature/order-cancel

A --- B --- C
          ↑
     리뷰 당시 상태

A --- B --- C --- D
                ↑
          수정 후 push

Pull Request를 제공하는 Git 호스팅 서비스는 소스 브랜치의 변경된 커밋을 감지하고 기존 Pull Request에 새로운 변경 내용을 표시합니다.

따라서 일반적인 처리 순서는 다음과 같습니다.

Request Changes
      ↓
코드 수정
      ↓
git add
      ↓
git commit
      ↓
git push
      ↓
기존 Pull Request 갱신
      ↓
리뷰어 재검토

여기서 git add, git commit, git push는 Git 기능이고, Pull Request가 갱신되고 리뷰 상태가 표시되는 부분은 Git 호스팅 서비스의 기능입니다.

---

Comment, Request Changes, Approve의 차이

Pull Request 리뷰에서는 보통 의견의 성격에 따라 Comment, Request Changes, Approve를 구분해서 사용합니다.

리뷰 방식	의미	사용 예
Comment	의견이나 질문을 남김	선택적인 개선 제안, 질문
Request Changes	수정이 필요하다는 리뷰 결과	merge 전에 반드시 수정해야 하는 문제
Approve	현재 변경 내용을 승인	코드에 문제가 없다고 판단한 경우

예를 들어 다음과 같은 의견이 있다고 하겠습니다.

order 대신 targetOrder라는 변수명을 사용하는 것도 좋을 것 같습니다.

반드시 수정해야 하는 사항이 아니라 단순한 제안이라면 Comment가 적절할 수 있습니다.

반면 다음처럼 실제 오류나 데이터 손실 가능성이 있다면 Request Changes를 사용하는 것이 적절합니다.

현재 코드에서는 주문 한 건을 취소하면서 전체 주문 데이터가 삭제될 수 있습니다.
merge 전에 반드시 수정해야 합니다.

수정 후 문제가 해결되었다면 리뷰어는 다시 코드를 확인하고 Approve할 수 있습니다.

Comment
→ 의견 또는 질문

Request Changes
→ 수정 필요

Approve
→ 현재 변경 사항 승인

GitHub 공식 문서에서도 Pull Request 리뷰를 제출할 때 comment, approve, request changes와 같은 리뷰 상태를 사용할 수 있다고 설명합니다.

---

Request Changes와 Merge 조건

Request Changes가 있다고 해서 모든 Git 호스팅 서비스에서 무조건 merge가 차단되는 것은 아닙니다.

실제 merge 가능 여부는 사용하는 서비스와 저장소의 보호 정책에 따라 달라집니다.

예를 들어 다음과 같은 정책을 사용하는 저장소가 있을 수 있습니다.

Required approvals: 1
변경 요청 리뷰가 남아 있으면 merge 금지

이 경우 리뷰 상태가 다음과 같다면 merge할 수 없습니다.

Reviewer A : Request Changes

작성자가 코드를 수정하고 다시 push합니다.

git add .
git commit -m "fix: 리뷰 내용 반영"
git push origin feature/order-cancel

리뷰어가 수정 내용을 확인한 뒤 승인합니다.

Reviewer A : Approve

이후 필요한 승인 수, 테스트 결과, 브랜치 보호 정책 등의 조건을 모두 만족하면 merge할 수 있습니다.

즉, 다음 두 가지를 구분해야 합니다.

Git
→ commit, branch, merge, push 등을 관리

Git 호스팅 서비스
→ Pull Request, Request Changes, Approve,
   Required Review, Branch Protection 등을 관리

Request Changes 자체를 Git의 merge 제한 기능이라고 이해하면 안 됩니다. merge 차단 여부는 GitHub, Gitea 등 사용 중인 협업 서비스의 저장소 정책에 따라 결정됩니다.

---

수정 커밋과 기존 승인 처리

Pull Request가 승인된 뒤 새로운 커밋이 추가되는 경우에도 저장소 정책을 확인할 필요가 있습니다.

예를 들어 처음에는 다음 상태였다고 가정하겠습니다.

Reviewer A : Approve

그 이후 작성자가 코드를 변경합니다.

git commit -m "feat: 추가 로직 반영"
git push origin feature/order-cancel

그러면 리뷰어가 승인할 당시 확인하지 않았던 새로운 코드가 Pull Request에 포함됩니다.

일부 Git 호스팅 서비스에서는 브랜치 보호 설정을 통해 새로운 커밋이 추가되었을 때 기존 승인을 무효화하고 다시 리뷰하도록 구성할 수 있습니다.

그 목적은 다음과 같은 상황을 방지하는 것입니다.

코드 A 리뷰
    ↓
Approve
    ↓
코드 B 추가
    ↓
코드 B는 리뷰하지 않음
    ↓
기존 Approve만으로 Merge

새로운 변경이 들어올 때마다 다시 검토하도록 운영하면 다음과 같은 흐름이 됩니다.

Approve
   ↓
새로운 commit push
   ↓
재검토 필요
   ↓
Approve
   ↓
Merge

이 동작은 Git 자체가 아니라 사용하는 Pull Request 서비스와 저장소의 리뷰 정책에 따라 달라집니다.

---

dev → stg Pull Request 적용 예제

다음과 같이 브랜치를 운영한다고 가정하겠습니다.

dev
 ↓
stg
 ↓
main

dev의 변경 사항을 stg에 반영하기 위해 Pull Request를 생성합니다.

source : dev
target : stg

리뷰어가 다음 문제를 발견합니다.

취소 처리에서 null 체크가 누락되어 있습니다.
merge 전에 수정이 필요합니다.

리뷰어가 Request Changes를 남깁니다.

작성자는 dev 브랜치에서 코드를 수정합니다.

git checkout dev
git pull origin dev

코드를 수정한 뒤 커밋합니다.

git add .
git commit -m "fix: 취소 처리 null 체크 추가"
git push origin dev

Git 저장소에는 새로운 커밋이 추가됩니다.

dev

A --- B --- C --- D
                ↑
         리뷰 반영 커밋

Pull Request 서비스에서는 기존 dev → stg Pull Request에 이 커밋이 추가된 상태로 표시됩니다.

리뷰어는 변경된 부분을 다시 확인합니다.

문제가 해결되었다면 Approve합니다.

dev → stg Pull Request
        ↓
Request Changes
        ↓
dev 코드 수정
        ↓
git commit
        ↓
git push origin dev
        ↓
기존 Pull Request 갱신
        ↓
재검토
        ↓
Approve
        ↓
Merge

따라서 특별한 이유가 없다면 다음과 같이 기존 Pull Request를 닫고 다시 만들 필요는 없습니다.

Request Changes
      ↓
기존 Pull Request Close
      ↓
새 Pull Request 생성

기존 Pull Request의 소스 브랜치에 수정 커밋을 추가하면 같은 리뷰 흐름을 계속 사용할 수 있습니다.

---

리뷰 상태에 따른 처리 흐름

리뷰어는 코드 상태에 따라 다음과 같이 판단할 수 있습니다.

코드 확인
   │
   ├─ 질문 또는 선택적인 제안
   │      └─ Comment
   │
   ├─ 반드시 수정해야 하는 문제
   │      └─ Request Changes
   │
   └─ 문제 없음
          └─ Approve

작성자는 Request Changes를 받은 경우 Pull Request를 새로 만드는 것이 아니라 기존 소스 브랜치를 수정하면 됩니다.

git checkout <source-branch>

# 코드 수정

git add .
git commit -m "fix: review changes"
git push origin <source-branch>

그 후 같은 Pull Request에서 재검토를 진행합니다.

---

Git과 Pull Request 기능의 관계

Git을 처음 사용할 때는 Pull Request도 Git 기능이라고 생각하기 쉽습니다.

하지만 역할을 나누어 보면 더 명확합니다.

Git에서 처리하는 부분

git checkout feature/order-cancel
git add .
git commit -m "fix: review changes"
git push origin feature/order-cancel

Git은 다음 정보를 관리합니다.

브랜치
커밋
파일 변경 이력
원격 저장소
push / pull / fetch
merge

Git 호스팅 서비스에서 처리하는 부분

GitHub, Gitea, GitLab 같은 서비스에서는 Git 저장소 위에 협업 기능을 제공합니다.

Pull Request / Merge Request
코드 리뷰
Comment
Request Changes
Approve
리뷰어 지정
Required approvals
브랜치 보호 정책
CI 결과와 merge 조건 연결

따라서 Request Changes를 받은 뒤 실제 코드를 수정하는 과정에서는 Git 명령을 사용하지만, Request Changes라는 상태 자체는 Git에 기록되는 기능이 아닙니다.

예를 들어 아래 명령은 존재하지 않습니다.

git request-changes

Git에서는 단순히 수정된 코드를 commit하고 원격 브랜치로 push합니다.

git add .
git commit -m "fix: review changes"
git push

그 결과를 Pull Request 서비스가 감지하여 리뷰 화면에 반영하는 구조입니다.

---

정리

Pull Request에서 Request Changes는 현재 변경 사항을 merge하기 전에 수정이 필요하다는 리뷰 결과입니다.

다만 Pull Request와 Request Changes는 Git 자체 기능이 아니라 GitHub, Gitea, GitLab 같은 Git 호스팅 서비스에서 제공하는 협업 기능입니다.

Git 관점에서 작성자가 해야 할 일은 단순합니다.

git checkout <source-branch>

# 코드 수정

git add .
git commit -m "fix: 리뷰 내용 반영"
git push origin <source-branch>

같은 소스 브랜치에 새로운 커밋을 push하면 Pull Request 서비스에서 기존 Pull Request에 변경 사항을 반영합니다.

전체 흐름은 다음과 같이 이해할 수 있습니다.

Pull Request 생성
        ↓
코드 리뷰
        ↓
Request Changes
        ↓
소스 브랜치 코드 수정
        ↓
git commit
        ↓
git push
        ↓
기존 Pull Request 갱신
        ↓
재검토
        ↓
Approve
        ↓
Merge

리뷰 상태는 다음 기준으로 구분하면 됩니다.

Comment
→ 의견이나 질문

Request Changes
→ merge 전에 수정이 필요한 사항

Approve
→ 현재 변경 사항 승인

그리고 실제 merge 차단 여부, 새로운 커밋이 추가되었을 때 기존 승인을 유지할지 여부 등은 사용하는 Git 호스팅 서비스와 저장소 보호 정책에 따라 달라집니다.

---

참고 자료

• Git 공식 문서: https://git-scm.com/docs/git
• Git 공식 git push 문서: https://git-scm.com/docs/git-push
• Git 공식 git checkout 문서: https://git-scm.com/docs/git-checkout
• Git 공식 git switch 문서: https://git-scm.com/docs/git-switch
• GitHub 공식 Pull Request 리뷰 문서: https://docs.github.com/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/about-pull-request-reviews
• GitHub 공식 Pull Request 변경 사항 리뷰 문서: https://docs.github.com/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/reviewing-proposed-changes-in-a-pull-request