요약

• git pull = git fetch + git merge
  • 기본적으로 git pull은 원격 브랜치의 변경사항을 가져오고(fetch), 현재 브랜치와 병합(merge)하여 새로운 merge commit을 만든다.
• git pull --rebase = git fetch + git rebase
  • --rebase 옵션을 사용하면 병합(merge) 대신 rebase를 수행하게 되어, 커밋 히스토리를 더 깔끔하게 유지할 수 있다.

---

예시로 보는 pull과 pull --rebase

현재 내 로컬 브랜치(main)와 원격 브랜치(origin/main)가 각각 커밋을 가진 상황이라면..?

o - o - o - H - A - B - C (main)
             \
              P - Q - R (origin/main)

git pull (기본 동작: merge)

o - o - o - H - A - B - C - X (main)
             \             /
              P - Q - R --- (origin/main)

• X: merge commit (두 브랜치를 병합한 커밋)
• 히스토리가 병합 형태로 남음

git pull --rebase

o - o - o - H - P - Q - R - A' - B' - C' (main)
                        |
                        (origin/main)

• 기존 커밋 A B C는 새로운 커밋 A' B' C'로 다시 쓰여짐
• 선형 히스토리를 유지
• 마치 내 작업이 최신 origin/main 위에서 바로 시작된 것처럼 보임

작업 내용은 동일하지만, 커밋 히스토리는 깔끔해짐
참고로 git fetch 후 git rebase origin/main을 사용하는 것도 같은 결과를 얻을 수 있음
git pull --rebase는 이 과정을 한 번에 처리하는 단축 명령어!

---

merge vs rebase: 커밋 히스토리 비교

git pull (기본 동작: merge)

• git pull은 내부적으로 git fetch와 git merge origin/<브랜치명>을 수행
• 병합 과정에서 merge commit이 생성
• 히스토리 특징
  • 시간순 + 브랜치가 섞인 구조
  • 중간중간 다른 커밋이 끼어들며 흐름이 복잡해질 수 있음
  • git log --graph로 보면 브랜치가 나뉘었다가 다시 합쳐지는 모습을 확인할 수 있음

git pull --rebase

• git pull --rebase는 내부적으로 git fetch + git rebase origin/<브랜치명>을 수행
• 즉, 내 커밋들을 기준 브랜치 끝으로 옮겨 새로 쌓는 작업을 함
  • 커밋 내용을 유지하되, 커밋 ID는 변경됨
• 히스토리 특징
  • 일직선(linear)
  • 마치 기준 브랜치에서 작업한 것처럼 정리됨
  • merge 커밋이 없어 히스토리가 깔끔하게 정리됨

정리하자면..

---

TIPS

주의사항

• 다른 사람이 이미 내 브랜치를 pull 했을 경우, rebase는 주의해야 함
  → 커밋 ID가 바뀌기 때문에 히스토리가 꼬일 수 있음

자주 사용하는 브랜치라면, 아래처럼 설정해두는 것도 가능

git config branch.<브랜치이름>.rebase true

혹은 전역으로

git config --global pull.rebase true

---

---

참고 자료

• Git 공식 문서 - git pull
  → “In its default mode, git pull is shorthand for git fetch followed by git merge FETCH_HEAD...”
  → “With --rebase, it runs git rebase instead of git merge.”
• Git Book - Rebase vs Merge
• Stack Overflow - git pull vs fetch + rebase