Git Fetch 개념 정립
🛰️ git fetch, 뭐가 있나 살펴보고 오는 것 — 어느 아침의 “왜 또 push 물어봐?” 사건
“push할까요?” — 어제 분명 다 push했는데, 오늘 아침 AI 코딩 도구가 또 물어본다.
알고 보니 범인은 딱 하나, git fetch를 오래 안 한 낡은 로컬이었다.
이 글은 그 하루 동안 벌어진 소동을 따라가면서 git fetch가 정확히 뭘 하는 명령인지,
그리고 “로컬 동기화 검토해줘”라고 했을 때 AI가 실제로 어떤 순서로 움직여야 하는지를 정리한 기록이다.
🌌 사건의 시작: 어제 분명 다 끝냈는데
전날 밤, 웹사이트 히어로 영역에 양각 텍스트 효과와 카드 애니메이션을 넣는 작업을 AI 코딩 도구로 진행했다. 작업이 끝나고 “서버에 배포해줘”라고 했더니 커밋·푸시·서버 반영까지 알아서 처리했다는 응답을 받았다. 그래서 그날은 그걸로 끝난 줄 알았다.
다음날 아침, 사무실 컴퓨터를 켜고 새 세션에서 습관처럼 이렇게 말했다.
“로컬 동기화 검토해줘~”
그런데 돌아온 대답이 예상 밖이었다.
가져오라고 답했더니, 파일들을 로컬로 옮기고 동기화 커밋을 만든 뒤 마지막에 이렇게 물었다.
여기서 이상함을 느꼈다. 어제 분명히 push까지 다 했다고 들었는데, 왜 오늘 또 push 여부를 묻는 거지?
🔍 범인 찾기: git fetch를 안 한 로컬
차근차근 다시 조사해보니 진짜 그림이 드러났다. 밤사이 AI 코딩 도구는 GitHub에 커밋을 정상적으로 push했다.
그런데 오늘 아침 사무실 PC는 그 사실을 몰랐다. 왜냐하면 사무실 PC가 그동안 git fetch를 하지 않아서,
로컬이 기억하고 있는 “GitHub의 최신 상태”가 며칠 전 것에 머물러 있었기 때문이다.
그 낡은 정보를 기준으로 서버와 비교하다 보니, 이미 GitHub에 올라가 있는 내용을 “GitHub엔 아직 없는 새 변경사항”으로 오판했고, 그래서 이미 끝난 push를 또 물어보는 상황이 벌어진 것이다. 실제로 push를 시도하는 순간 GitHub의 진짜 최신 상태가 드러났고, 비교해보니 방금 만든 동기화 커밋은 이미 있는 내용과 완전히 같은 중복 작업이었다.
📡 그래서 git fetch가 정확히 뭐하는 명령인가
git fetch는 한마디로 “저 옆 동네(GitHub)에 가서, 요즘 뭐가 새로 생겼는지 살펴보고 정보만 갱신해서 돌아오기”다.
실제로 내 컴퓨터의 작업 파일은 전혀 건드리지 않는다. 그저 “GitHub엔 지금 여기까지 커밋이 있더라”는
지도(색인)만 최신으로 바꿔놓을 뿐이다.
그래서 git fetch origin은 “GitHub에 뭐가 있나 한번 보고 오자” 정도로 이해하면 딱 맞다.
언제 실행해도 로컬 파일에 부작용이 없으니, 작업을 시작하기 전에는 습관처럼 먼저 해두는 게 안전하다.
🗺️ 이번 사건이 특히 헷갈렸던 이유: 기준점이 3개였다
보통의 git 사용은 “로컬 ↔ GitHub” 두 지점만 신경 쓰면 된다. 그런데 이번 구조는 여기에 “운영 서버”라는 세 번째 지점이 끼어 있었다. 로컬에서 작업한 뒤 GitHub에 push하고, 서버는 GitHub에서 pull해서 배포하는 게 정상 경로지만, 급할 때 서버에 직접 SSH로 들어가 파일을 고치는 경우도 있다 보니 세 지점이 서로 다른 속도로 어긋날 수 있었다.
🧭 “로컬 동기화 검토해줘~” — 완료까지의 전체 절차
이번 소동을 겪고 나서, “로컬 동기화 검토해줘”라는 한마디에 AI 도구가 실제로 밟아야 할 순서를 정리했다. 핵심은 항상 GitHub를 가장 먼저, 가장 최신으로 만들어 놓고 그다음에 서버와 비교하는 것이다.
- GitHub 최신 상태 가져오기 —
git fetch origin으로 origin/main 정보를 갱신한다. 이걸 빼먹으면 이미 push된 내용을 “새 변경사항”으로 착각하는 오늘 같은 오탐이 생긴다. - 서버 쪽 상태 가져오기 — SSH 또는 서버를 가리키는 원격(예: server-tmp)을 fetch해서 서버에 지금 어떤 파일/커밋 상태가 있는지 확인한다. 서버는 GitHub를 거치지 않고 직접 바뀔 수 있으므로 반드시 별도로 확인해야 한다.
- 로컬 vs origin/main 비교 —
git log origin/main..HEAD(로컬에만 있는 커밋),git log HEAD..origin/main(GitHub에만 있는 커밋)을 확인한다. 로컬이 뒤처져 있으면 먼저 pull/merge로 로컬을 최신화한다. - origin/main vs 서버 실제 상태 비교 — 최신화된 로컬(=GitHub 최신)과 서버를
git diff origin/main server-tmp/main --stat등으로 비교해, 진짜로 서버에만 있고 GitHub엔 없는 변경이 있는지 확인한다. - 차이가 있으면 파일 단위로 검토 — 코드처럼 실제 반영해야 할 변경인지, 스크린샷 같은 무시해도 되는 바이너리인지 구분한다. 바로 반영하지 않고 먼저 사람에게 어떤 차이가 있는지 보고한다.
- 필요한 파일만 로컬로 반영하고 커밋 — 진짜 서버 전용 변경 파일만 골라 가져오고, 어떤 파일을 왜 가져왔는지 커밋 메시지에 명확히 남긴다.
- GitHub로 push하고 3자 일치 확인 — 새 커밋을 push한 뒤, 로컬·GitHub·서버 세 곳의 최신 상태가 모두 같은지 마지막으로 다시 확인하고 마무리한다.
🎯 결국 한 문장으로 요약하면
지금까지의 모든 과정 — fetch, pull, diff, push — 은 결국 하나의 질문에 답하기 위한 것이다. “로컬, GitHub, 서버 이 세 군데가 지금 정확히 같은 내용을 갖고 있는가?”
git fetch origin으로 GitHub 최신 정보를 먼저 확보한다 — 이게 항상 기준점이다.- 로컬이 origin보다 뒤처져 있으면 pull 등으로 로컬을 origin에 맞춘다.
- 그다음 origin과 서버를 비교한다. 이때 갈리는 경우는 세 가지다.
- 서버에만 있고 origin엔 없는 커밋 → 서버 작업이 push되지 않은 것 → 로컬로 가져와 push한다.
- origin에만 있고 서버엔 없는 커밋 → 로컬→서버 배포가 빠진 것 → 서버에 배포해야 한다.
- 둘 다 있는데 서버가 커밋을 안 남겨서 겉보기엔 차이가 있어 보이지만 실제 파일은 origin과 같은 상태인 경우도 있다 — 그래서 커밋 로그만이 아니라 실제 파일 diff까지 봐야 확실하다(오늘 실제로 이 경우였다).
결과적으로 로컬 동기화 검토의 최종 목적은, GitHub(origin)를 언제나 흔들림 없는 단일 기준점으로 유지하고, 로컬과 서버를 그 기준에 맞추는 작업이라는 한 문장으로 정리된다.
💡 오늘의 교훈
git fetch는 정보만 갱신하는 조회 동작이라 아무리 자주 해도 안전하다. 작업 시작 전 습관처럼 실행해두자.- “push할까요?”라는 질문을 받으면, 그게 진짜 새 내용인지 아니면 낡은 로컬 정보 때문에 생긴 오탐인지 한 번 의심해볼 가치가 있다.
- 기준점이 세 곳(로컬·GitHub·서버) 이상으로 늘어나는 배포 구조에서는, 항상 가장 신뢰할 수 있는 중앙(GitHub)을 먼저 최신화한 뒤 나머지를 비교하는 순서를 지키는 게 혼란을 줄이는 길이다.
이 글은 AI 코딩 도구와 함께 작업하다 실제로 겪은 git 동기화 소동을 바탕으로, git fetch의 개념을 정리하기 위해 작성한 기록이다. 서버 주소·저장소 이름 등 민감 정보는 일반화하여 표기했다.