[Git] Pull Request 개념 다시 정리하기

오늘 특강을 통해 Pull Request의 개념과 Conflict 발생 시에 해결할 수 있는 내용들을 정리하고자 한다.

 

❓Pull Request는 언제 사용되는가?

: 내가 만든 브랜치의 변경사항을 다른 브랜치(보통의 경우 main)에 합치자는 제안

→ 협업 환경에서 코드 변경을 공식적으로 검토하고 병합 요청하는 절차

 

쉽게 말해서 main 브랜치에서는 완전한 기능수행을 할 수 있는 환경만 배포한다는 가정일 때 다른 브랜치로 분기점을 설정, 그 브랜치에서 수정 및 변경과정을 거치고 병합하는 과정이라고 할 수 있다.

 

⚠️ 무엇을 유의해야할까?

협업 관계에서 Conflict(충돌) 현상은 발생할 수 밖에 없는 불가피한 상황이다. 그 덩어리 자체를 줄이기 위해 매우 작은 단계로 Commit하고 분기점에서 main 분기점으로 빠르게 복귀할 수 있게 구현하는 습관이 필요하다. 

 

또한 내가 가지고 있는 로컬 main 파일의 내용이 항상 최신화된 내용으로  유지될 수 있도록 pull(최신화) 하는 과정도 중요하다는 점을 깨달았다.

 

아래는 내가 실제로 실습하면서 확인했던 내용이다.

 

1. 실습의 전체 흐름 요약

단계	설명
Step 1. main 브랜치에서 두 개의 실험 브랜치 분기	experiment/conflict-A, experiment/conflict-B
Step 2. 각 브랜치에서 User.java의 같은 줄을 다르게 수정	A → username, B → fullName
Step 3. A 브랜치를 먼저 GitHub에 PR 생성 후 Merge	main이 username 변경으로 업데이트됨
Step 4. B 브랜치를 나중에 PR 생성	main과의 같은 줄 차이로 충돌 발생 (username vs fullName)
Step 5. 로컬에서 git fetch origin → git merge origin/main 으로 충돌 해결
Step 6. 수정 후 커밋/푸시 → PR 자동 갱신 → Merge 완료

 

2. 충돌이 발생한 이유

두 브랜치 모두 User.java의 같은 위치를 수정함

pirvate String name;

 

브랜치	수정 내용
conflict-A	private String username;
conflict-B	private String fullName;

 

Git 입장에서는 같은 줄이 서로 다르게 바뀌게 되며 어느 브랜치의 수정사항을 기준으로 해야하는지 모르기 때문에 conflict가 발생하게 된 것

 

3. 충돌 해결 방법

원하는 결과를 직접 선택하거나 병합한 이후 커밋을 통해 Conflict 상황을 해소하고, 이후 Conflict resolved 처리가 되면 Merge 할 수 있는 PR의 상황을 확인할 수 있게 됨

 

이 과정을 터미널로 진행했던 내용을 정리하자면 아래와 같다.

 

# main 브랜치 기준으로 분기
git checkout main
git checkout -b experiment/conflict-A

# conflict-A 수정
git add .
git commit -m "refactor(user): rename name -> username"
git push -u origin experiment/conflict-A
# → GitHub에서 PR #1 생성 및 merge 완료

# 다시 main으로 복귀 후 B 브랜치 생성
git checkout main
git pull
git checkout -b experiment/conflict-B

# conflict-B 수정
git add .
git commit -m "refactor(user): rename name -> fullName"
git push -u origin experiment/conflict-B
# → GitHub에서 PR #2 생성 (⚠️ 충돌 표시)

# 로컬에서 충돌 해결
git fetch origin
git merge origin/main     # conflict 발생
# → User.java 수정 후
git add .
git commit -m "fix: resolve merge conflict"
git push                   # PR 자동 업데이트 → merge 가능

 

이를 통해 PR의 생성 및 충돌상황인 경우에 처리하는 방법을 알게 되었고, 작은 단위로 기록을 세세하게 남겨놓는 것, 브랜치의 생명주기를 짧게 두는 것이 중요하다는 것을 알게 되었다.