Tech Notes

GitHub PR에서 Merge Conflict란?

miracle-tech 2026. 4. 7. 10:55
728x90
반응형

GitHub Pull Request에서 "Squash and Merge"를 누르면 충돌이 생기는 걸까? PR 체크 실패, 리뷰 미승인, Merge Conflict의 차이를 코드 예시와 함께 명확하게 정리합니다.

목차

  1. GitHub PR이 머지되지 않는 3가지 이유
  2. Merge Conflict란 정확히 무엇인가
  3. Squash and Merge vs Conflict — 어떤 관계인가
  4. Conflict 해결하는 법 (실전 명령어)
  5. Merge 방식 3가지 비교
  6. 정리 한 줄 요약

1. GitHub PR이 머지되지 않는 3가지 이유

PR을 올렸는데 머지가 안 된다면, 보통 아래 3가지 중 하나입니다.

 

원인 설명 해결 방법
Review required 리뷰어 N명의 Approve가 아직 없음 팀원에게 리뷰 요청
CI/CD 체크 실패 Unit test, SonarCloud 등 자동 체크 실패 코드 수정 후 재push
Merge Conflict 같은 파일·같은 줄을 여러 사람이 수정 충돌 수동 해결

Bypass rules and merge는 관리자 권한이 있을 때만 사용 가능한 강제 머지 옵션입니다.
프로덕션 코드에는 신중하게 사용하세요.

2. Merge Conflict란 정확히 무엇인가

Conflict는 같은 파일의 같은 줄을 두 사람이 동시에 수정했을 때, Git이 "어느 버전을 써야 해?"라고 묻는 상황입니다.

# Conflict 발생하는 케이스
다른 사람 → UserService.java 10번째 줄 수정
나          → UserService.java 10번째 줄 수정
결과        → ⚠️ CONFLICT

# Conflict 발생하지 않는 케이스
다른 사람 → UserService.java 수정
나          → OrderService.java 수정
결과        → ✅ No conflict (파일 자체가 다름)

# 같은 파일이지만 다른 줄인 경우
다른 사람 → UserService.java 10번째 줄 수정
나          → UserService.java 50번째 줄 수정
결과        → ✅ No conflict (줄이 다름)

3. Squash and Merge vs Conflict — 어떤 관계인가

많은 분들이 "Squash and Merge를 하면 충돌이 생기는 것 아닌가?"라고 오해하는데, 전혀 그렇지 않습니다.

Squash and Merge는 Conflict가 이미 없을 때 선택하는 "어떤 방식으로 합칠까"의 옵션입니다.
Conflict가 있으면 머지 버튼 자체가 비활성화됩니다.

 

브랜치 관계를 시각화하면 이렇습니다:

# 충돌 없는 상태 (Squash and Merge 가능)

main:      A → B → C  ← 다른 사람이 먼저 머지한 커밋
                   ↑
내 브랜치:  A → B → D  ← 내가 작업한 커밋

C와 D가 건드린 파일이 다름 → Conflict 없음 ✅
→ Squash and Merge 선택 가능

즉, "최신 소스가 다른 사람 것이지만, 내가 건드린 파일과 겹치지 않는다"는 뜻이 Conflict 없음입니다.

4. Conflict 해결하는 법 (실전 명령어)

Conflict가 발생했다면 GitHub 웹에서 해결하거나, 로컬에서 아래 명령어로 해결합니다.

# 1. 내 브랜치로 이동
git checkout 내브랜치

# 2. 최신 main 가져오기
git fetch origin

# 3. rebase로 충돌 확인
git rebase origin/main
# → 충돌 난 파일 열어서 수동 수정

# 4. 수정 완료 후
git add .
git rebase --continue

# 5. 원격 브랜치에 강제 push
git push origin 내브랜치 --force

⚠️ --force push는 PR 브랜치에만 사용하세요. main/master 브랜치에 force push는 절대 금지입니다.

5. Merge 방식 3가지 비교

Conflict가 없는 상태에서 머지할 때, 어떤 방식을 선택하느냐에 따라 커밋 히스토리 모양이 달라집니다.

방식 설명 히스토리 추천 상황
Create a merge commit 브랜치의 모든 커밋을 그대로 보존 + merge commit 추가 복잡 커밋 히스토리를 모두 보존하고 싶을 때
Squash and merge 브랜치의 모든 커밋을 1개로 압축해서 main에 추가 깔끔 ✅ WIP 커밋이 많아서 정리하고 싶을 때 (가장 무난)
Rebase and merge 커밋을 main 위에 순서대로 재배치 선형 merge commit 없이 선형 히스토리를 유지하고 싶을 때

 

팀 컨벤션이 없다면 Squash and merge가 가장 무난한 선택입니다.

6. 정리 한 줄 요약

  • Conflict = 같은 파일·같은 줄을 두 사람이 수정했을 때, 머지 전에 해결해야 하는 것
  • Squash and merge = Conflict 없을 때 "어떤 방식으로 합칠까"를 선택하는 옵션
  • 둘은 순서가 다른 개념입니다. Conflict 먼저 해결 → 그 다음 머지 방식 선택
728x90