git fetch, git rebase, git pull 차이와 실전 사용법

---

1. git fetch – "최신 정보를 가져오기만 해!"

git fetch origin

• 원격 저장소의 변경사항을 가져오되, 내 로컬 브랜치에는 적용하지 않음
• 단지 .git 디렉토리 내부의 정보를 최신화
• git log origin/main 혹은 git diff origin/main 등으로 확인 가능

언제 쓰냐?

• 변경사항을 확인하고 싶지만, 아직 내 코드에 적용하고 싶지 않을 때
• 특히 CI/CD로 충돌을 미리 체크하고 싶을 때 아주 유용

---

2. git rebase – "내 작업을 최신 커밋 위에 깔끔하게 다시 올려줘"

git rebase origin/main

• 현재 브랜치에 있는 커밋을, 원격 브랜치의 최신 커밋 이후로 옮김
• 즉, 내가 한 작업을 나중에 한 것처럼 만들기 (히스토리가 깨끗해짐)
• 충돌이 날 수 있지만, 충돌을 직접 해결할 수 있어서 협업에 적합

언제 쓰냐?

• 팀에서 rebase 전략을 쓰는 경우
• 커밋 로그를 깔끔하게 유지하고 싶을 때

주의!

• rebase는 공유된 브랜치에서는 신중히!
  git push --force가 필요할 수 있음. 잘못 쓰면 동료의 작업이 날아갈 수 있음.

---

3. git pull – "최신 걸 가져오고 바로 병합해줘"

git pull origin main

• git fetch + git merge를 한 번에 수행
• 가장 많이 쓰이지만, 커밋 히스토리가 지저분해질 수 있음
• 충돌도 발생 가능

🔧 언제 쓰냐?

• 혼자 작업할 때 빠르게 최신화하려면 편함
• 그러나 팀 협업에서는 **의도치 않은 병합 커밋(Merge commit)**이 생겨 버그 추적이 힘들 수 있음

---

실전 예시

협업 중이라면?

git fetch origin
git rebase origin/main

✔️ 충돌을 내가 직접 해결하면서 커밋 히스토리를 깔끔하게 유지할 수 있음

---

그냥 빠르게 동기화하고 싶다면?

git pull origin main

✔️ 단, 히스토리 관리에 민감하지 않을 때만

---

추가 꿀팁

차이점 비교 요약

명령어	원격 변경사항 반영	로컬 히스토리 변경	충돌 해결 방식
git fetch	❌ (보기만 함)	❌	없음
git rebase	✅	✅ (히스토리 수정)	직접 해결 필요
git pull	✅	✅ (병합)	자동 or 수동 병합

---

마무리하며

예전엔 git pull만 써도 충분했지만,
협업이 잦아지고 충돌/히스토리 문제가 늘어나면서
fetch + rebase 조합을 더 많이 쓰게 되더라구요.

실제로 큰 서비스팀에서 일할수록, 커밋 하나하나가 버그 추적의 단서가 되기 때문에
rebase를 쓰는 게 디폴트인 팀도 많아요.