[📰 위클리페이퍼] Git rebase VS Git merge / Git fetch VS Git pull

📌 rebase VS fetch

💻 git rebase

• 개념

  내 브랜치의 커밋들을 기준 브랜치 위에 다시 쌓음
  결과적으로 히스토리가 일직선(linear) 이 됨

👍 장점
1. 히스토리가 아주 깔끔함

2. 불필요한 merge commit 없음

3. 로그 읽기 쉬움

👎 단점

1. 커밋 해시가 바뀜

2. 이미 공유된 브랜치에서 쓰면 사고 남

3. conflict가 커밋 단위로 여러 번 날 수 있음

🧐 그럼 언제 rebase를 쓰는지?

1. 혼자 작업하는 feature 브랜치

2. PR 올리기 전에 커밋 정리

3. main 최신 커밋을 반영하고 싶을 때

💁 요약

"히스토리 정리용 도구" 느낌
-> 노트정리 정도로 이해하면 쉬울듯
(정리 된 내용 뒤에 공부한 내용을 옮겨 적는 느낌)

💻 git merge

• 개념

  두 브랜치를 그대로 합치고 merge commit이라는 새로운 커밋을 하나 생성함
  기존 커밋 히스토리를 절대 수정하지 않음

👍 장점

1. 히스토리가 실제 작업 흐름 그대로 남음

2. 협업 시 안전함 (공유 브랜치에 적합)

3. conflict가 한 번에 발생

👎 단점

• merge commit이 많아지면 히스토리가 복잡해짐

🧐 그럼 언제 merge를 쓰는지?

1. 팀 협업

2. 이미 원격에 공유된 브랜치

3. main, develop 같은 중요 브랜치

4. “언제 어떤 브랜치가 합쳐졌는지”가 중요한 경우

📌 fetch VS pull

💻 git fetch

• 개념

  원격 저장소의 최신 변경 사항을 로컬로 가져오기만 함
  내 작업 브랜치에는 아무 변화도 없음
  변경 사항은 origin/main 같은 원격 추적 브랜치에만 반영됨

🧐 그럼 fetch를 사용하면 상태는 어떻게 변화하는지?

❌ working directory 변경 없음
❌ 현재 브랜치 변경 없음
⭕ 원격 브랜치 정보만 업데이트
📌 갱신과 비슷한 느낌이라 변경 사항을 확인 후 직접 합쳐야 함!

💻 git pull

• 개념

  git fetch + git merge (기본)
  -> 가져오자마자 바로 합침

🔍 pull 사용시 git 내부 과정

git fetch origin
git merge origin/main

🧐 그럼 pull 사용하면 상태는 어떻게 변화하는지?

⭕ 현재 브랜치가 바로 변경됨
‼️ 충돌 발생 가능 ‼️

---

참고
https://kr.linkedin.com/pulse/what-git-merge-difference-between-rebase-shruthi-rajkumar?tl=ko