협업을 위한 Git 기초 6 | Pull Request(PR)와 코드 리뷰 구조 이해

목차

1. Pull Request란 무엇인가?
2. 2가지 협업 모델
3. Fork란 무엇인가?
4. Origin과 Upstream 차이
5. PR 생성 과정
6. Merge 방식 3가지
7. 협업 흐름 정리 

 

1. Pull Request란 무엇인가?

 

Pull Request(PR)란 새로운 코드 변경사항을 원본 소스에 병합하기 위해 제안하는 것이다.

 

즉, 나의 브랜치 변경사항을 원본 소스에 병합하기 전에 다른 사람에게 확인을 요청하는 과정이다.

PR은 단순한 병합 명령이 아닌, 코드 리뷰와 검토 과정을 포함하는 협업 절차이다.

 

Q. 왜 바로 merge하지 않을까?

 

기초 5에서는 '작업 -> commit -> push -> fetch  -> merge' 와 같은 흐름을 배웠다.

하지만, 실제 협업 과정에서는 누군가 main 브랜치에 직접 merge하지 않는다.

 

그 이휴는 다음과 같다.

• 코드 품질 유지
• 버그 방지
• 보안 검토
• 협업 안정성 확보
• 변경 이력 관리

2. 2가지 협업 모델

 

GitHub에서의 협업은 크게 두 가지 방식으로 이루어진다.

1. 팀 내부 협업 모델
2. Fork 기반 협업 모델 (오픈소스 기여)

1번 방법은 회사나 팀 프로젝트에서 자주 사용된다. 

 

• 같은 저장소에서 작업
• 브랜치 생성
• push
• Pull Request 생성
• 리뷰 후 merge

 

2번 방법은 오픈소스 프로젝트에서 많이 사용된다.

 

• 같은 저장소에서 작업
• 브랜치 생성
• push
• Pull Request 생성
• 리뷰 후 merge

 

3. Fork란 무엇인가?

 

Fork는 다른 사람의 저장소를 내 GitHub 계정으로 복사하는 기능이다.

 

Fork를 하면 다음과 같은 구조가 만들어진다.

Upstream (공식 저장소)
      ↓ Fork
내 GitHub 저장소 (Origin)

 

내 Origin 저장소에는 push할 수 있지만, 공식 Upstream 저장소에는 직접 push할 수 없다.

변경사항을 반영하려면 Upstream으로 Pull Request를 보내야 한다.

 

4. Origin과 Upstream 차이

 

Origin이란 내가 Fork한 저장소로, 내가 push할 수 있는 저장소를 의미한다.

로컬 저장소와 기본적으로 연결되어 있다. 

 

Upstream이란 원본 공식 저장소로, 직접 push할 수 없는 저장소이다.

Pull Request를 보내 merge하기 전 확인을 받고 승인이 되어야 한다.

 

 

GitHub PR 구조 예시

 

위 그림은 Fork 기반 협업 구조를 나타낸다.

• 가장 위의 Upstream Repository는 공식 저장소이다.
• 각 개발자는 이 저장소를 Fork하여 자신의 Origin Repository를 가진다.
• 각자의 로컬 저장소(Local Repository)에서 작업하고 commit을 생성한다.
• 변경사항은 자신의 Origin Repository로 push된다.
• 이후 Upstream Repository로 Pull Request를 요청한다.

이 구조에서 중요한 점은 아래와 같다.

• 공식 저장소에는 직접 push하지 않는다.
• 반드시 Pull Request를 통해 병합된다.

 

5. PR 생성 과정

5-1 원본 저장소 Frok

기여하기 원하는 레포지토리의 우측 상단에 포크 부분을 눌러 Fork한다.

Fork가 완료되면 자신의 원격 저장소에 포크한 레포지토리가 복제된다.

Github Fork 사진

 

5-2 Fork한 저장소를 로컬로 git clone

이제 내 GitHub 계정에 생성된 Fork 저장소를 로컬로 가져온다.

$ git clone "원격저장소주소"

 

현재 상태 확인

$ git remote -v

 

출력 예시

처음에는 origin만 등록된 상태가 뜬다.

origin  https://github.com/내계정/프로젝트.git (fetch)
origin  https://github.com/내계정/프로젝트.git (push)

 

5-3 원본 저장소 upstream 설정

 

Fork 기반 협업에서는 원본 저장소를 별도로 연결해줘야 한다.

$ git remote add upstream "원본저장소주소"

 

현재 상태 확인

$ git remote -v

 

 

출력 예시

origin    https://github.com/내계정/프로젝트.git (fetch)
origin    https://github.com/내계정/프로젝트.git (push)
upstream  https://github.com/원본계정/프로젝트.git (fetch)
upstream  https://github.com/원본계정/프로젝트.git (push)

 

즉, origin은 내가 push하는 저장소이고 upstream은 PR 대상인 공식 저장소이다.

 

5-4 Branch 생성

main에서 바로 작업하지 않고, 새로운 Branch를 생성한다.

 

예를 들어, 기능 중에 로그인을 구현한다면 feature/login이라는 Branch를 생성한다.

$ git switch -c feature/login

 

브랜치 확인 명령어

$ git branch

 

5-5 코드 작업 및 git add, git commit, git push

코드를 수정한 뒤 add와 commit을 해준다.

$ git add .
$ git commit -m "Add input validation to prevent XSS"

 

그다음 나의 origini으로 push를 한다.

$ git push origin feature/login

 

5-6 Pull Request 생성

1. 내 Fork 저장소로 이동하기
2. 'Compare & pull request' 클릭하기
3. 설명 작성 후 Create Pull Request(어떤 기능을 어떻게 수정했는지 자세히 작성할 것)

 

5-7 Merge Pull Request

리뷰가 완료되면 Upstream 저장소 관리자가 PR을 merge(병합)한다.

승인되면 pull request의 상태는 closed로, 거절되면 reject으로 바뀐다.

 

Merge 방식은 보통 3가지가 있으며, 기초 단계에서는 merge commit만 이해해도 충분하다.

1. Create a merge commit
2. Squash and merge
3. Rebase and merge

 

5-8 Merge 이후 동기화 및 Branch 삭제

PR이 merge되면 내 Fork와 로컬을 최신 상태로 맞춰야 한다.

그리고 작업하던 로컬의 branch는 더이상 사용을 안하기 때문에 삭제한다.

 

 

Upstream 최신화

$ git fetch upstream
$ git switch main
$ git merge upstream/main

 

내 Fork(origin)에도 반영

$ git push origin main

 

작업 브랜치 삭제

$ git branch -d feature/login
$ git push origin --delete feature/login

 

6. Merge 방식 3가지

 

GitHub에서는 3가지 Merge 방식을 제공한다.

 

6-1 Create a merge commit (기본)

PR 브랜치의 변경사항을 main에 합치면서, Git이 “merge commit”이라는 새로운 커밋 1개를 추가로 생성한다.

• 장점: 브랜치가 언제 병합됐는지, PR 단위의 맥락이 히스토리에 명확히 남는다.
• 단점: PR이 많아지면 merge commit이 누적되어 히스토리가 다소 복잡해질 수 있다.

📌 이런 팀에 잘 맞음

• “PR 단위 기록”을 중요하게 보고, 히스토리를 있는 그대로 보존하고 싶은 경우
• 기초 단계/팀 프로젝트에서 가장 무난한 선택

Merge Commit

6-2 Squash and merge

PR 안에 여러 개의 커밋이 있어도, 병합할 때 모든 커밋을 하나로 “압축(squash)”해서 1개의 커밋으로 만든 뒤 main에 병합하는 방식이다.

• 장점: main 브랜치 히스토리가 깔끔해진다(기능 하나 = 커밋 하나처럼 보이게 관리 가능).
• 단점: PR 안에서 쌓아둔 “중간 커밋(실험/수정 과정)”의 기록이 main 히스토리에는 남지 않는다.

📌 이런 팀에 잘 맞음

• main 히스토리를 “기능 단위”로 깔끔하게 유지하고 싶은 경우
• 커밋 관리 규칙(커밋 컨벤션)이 강한 팀

Squash and merge

6-3 Rebase and merge

PR 브랜치의 커밋들을 main 브랜치의 최신 커밋 뒤로 “재배치(rebase)” 한 뒤, merge commit 없이 직선 형태로 병합하는 방식이다.

• 장점: 히스토리가 직선으로 이어져서 흐름을 따라가기 쉽다(merge commit이 생기지 않음).
• 단점: rebase 과정에서 커밋이 “재작성”될 수 있어(커밋 해시 변경), 협업 규칙을 모르면 혼란이 생길 수 있다.

📌 이런 팀에 잘 맞음

• “선형(linear) 히스토리”를 강하게 선호하는 경우
• rebase에 익숙하고 규칙을 잘 지키는 팀

 

Rebase and merge

---

모듈 프로젝트나 소규모 팀 협업에서는 기본적으로 Create a merge commit 방식을 사용하는 것이 가장 무난하다.

이 방식은 PR 단위의 병합 기록이 명확히 남기 때문에 누가 언제 어떤 기능을 합쳤는지 추적하기 쉽다.

Squash와 Rebase 방식은 히스토리를 더 깔끔하게 만들 수 있지만, 협업 규칙이 명확하지 않으면 오히려 혼란을 줄 수 있다.

따라서 기초 단계에서는 기본 merge commit 방식을 이해하고 사용하는 것이 가장 안정적이다.

---

👉[Git] reset / revert 차이 + checkout

👉 Conventional Commits