git fetch
Download objects and refs from another repository
— Git 공식 매뉴얼(git-fetch Manual Page)
"머지가 터질까 봐 무서워서 풀은 못 치겠고, 일단 무슨 변화가 생겼나 훔쳐만 볼 때 쓴다." 소심한 자들의 안전하고 은밀한 염탐 도구
1. 개요
Git에서 원격 저장소의 최신 데이터(커밋 히스토리, 브랜치 상태 등)를 긁어오되, 내 현재 작업 중인 코드와 무단으로 병합(Merge)하지는 않는 아주 조심스럽고 똑똑한 명령어이다. 원격의 최신 소식을 업데이트만 해놓고, 로컬 저장소의 고요함을 깨뜨리지 않은 채 안전지대에서 간을 볼 때 주로 애용된다.(...)
2. 관조의 미학: 안전한 탐색과 정찰
git pull이 앞뒤 안 가리고 문을 벌컥 열어 원격의 군대(코드)를 들이는 성급함이 있다면, git fetch는 망루 위에서 망원경으로 '적국에 무슨 변화가 생겼나' 조용히 살피는 정찰병에 가깝다. 패치를 실행하면 원격 저장소의 최신 커밋들이 로컬 내의 숨겨진 원격 추적 브랜치(origin/main 등)로만 다운로드되며, 내가 지금 땀 흘려 코딩하고 있는 파일들에는 아무런 영향을 주지 않는다.1 따라서 변경 사항을 찬찬히 뜯어보고 안전하다고 판단될 때 비로소 수동으로 병합하는 프로세스가 가능하다.
3. 실무자들의 냉대: '귀찮은데 그냥 Pull 때리죠?'
이처럼 깃을 정석적으로 다루는 교과서적 가이드에서는 항상 git fetch를 먼저 치고 차이점을 확인(git diff)한 후 병합하라고 권장한다. 하지만 현실은 냉혹한 마감 시간의 노예인 개발자들에게 그런 사치는 사치일 뿐이다.(...) 대다수의 필드 개발자들은 묻지도 따지지도 않고 곧바로 git pull 엔터를 갈기는 것이 일상화되어 있어, fetch 명령어는 그저 풀이 내부적으로 호출하는 서브루틴 정도로만 취급받는 안습한 위상을 자랑한다.2
4. 실제 사용 예시
원격 저장소의 최신 상태를 가져오되 내 작업 브랜치에는 바로 섞지 않는 안전한 확인용 흐름이다.
git fetch origin
git status -sb
git log --oneline main..origin/main
삭제된 원격 브랜치 정리까지 함께 하려면 prune 옵션을 자주 쓴다. 확인 후 직접 merge나 rebase를 선택할 수 있다.
git fetch --all --prune
git merge origin/main
# 또는
git rebase origin/main
5. 관련 밈 및 드립
5.1. Schrodinger's Conflict (슈뢰딩거의 충돌)
풀을 땡기기 전까진 충돌이 난 상태와 나지 않은 상태가 공존하므로, 무서워서 풀은 못 누르고 하루 종일 fetch만 백 번 누르며 원격의 커밋 로그만 원망스럽게 쳐다보는 쫄보 개발자의 넋두리를 풍자한 드립.
6. 여담
- 삭제된 브랜치 정리하기: 원격에서 지워진 브랜치가 내 로컬에 여전히 유령처럼 남아있을 때,
git fetch --prune(또는-p)을 때려주면 깔끔하게 유령 브랜치들을 소탕해 준다. 깃 정리정돈의 핵심 스킬이다. - 공기 같은 존재: 실제로 깃 입문자 중 상당수는 독립적인
fetch명령어의 용도를 평생 모른 채 주니어 생활을 마감하기도 한다.(...)