Git push와 pull을 보내기와 받아오기로 구분하는 법

Git으로 저장했다는 말과 GitHub에 올라갔다는 말은 같은 상태가 아닙니다. 내 컴퓨터에서 커밋을 만들었어도 원격 저장소에 보내지 않았다면 다른 사람은 볼 수 없습니다. 반대로 원격에 새 커밋이 생겨도 내 컴퓨터로 받아오지 않으면 로컬 화면은 예전 상태일 수 있습니다.

로컬 저장소는 내 책상 위 작업 장부이고 원격 저장소는 팀이 함께 보는 보관함이라고 생각하면 쉽습니다. push는 보관함으로 보내는 동작이고 fetch는 보관함의 새 목록을 읽어 오는 동작입니다. pull은 목록만 읽는 데서 끝나지 않고 내 작업 줄기에 합치기까지 시도합니다.

origin은 원격 저장소에 붙인 별명이다

원격 저장소는 네트워크에 있는 Git 저장소입니다. GitHub, GitLab 같은 서비스나 회사 서버가 될 수 있습니다. origin은 복제할 때 흔히 붙는 기본 별명일 뿐 반드시 GitHub를 뜻하지 않습니다. remote는 멀리 있다는 뜻보다 다른 저장소 연결 정보를 가리키는 말입니다.

현재 연결은 git remote -v로 읽을 수 있습니다. 주소에 접근 토큰이나 비밀번호가 포함돼 있다면 화면 공유에 노출하지 않습니다. 회사 저장소 URL도 외부 글이나 공개 이슈에 그대로 붙이지 말아야 할 수 있습니다.

$ git remote -v
origin  https://github.com/example/my-app.git (fetch)
origin  https://github.com/example/my-app.git (push)

fetch와 push 주소가 따로 보일 수 있습니다. 같은 origin이라도 가져오는 주소와 보내는 주소가 다르게 설정될 수 있으므로 이름만 보고 권한을 단정하지 않습니다.

fetch는 원격 기록을 내려받되 현재 파일을 합치지 않는다

git fetch는 원격의 커밋과 브랜치 정보를 내려받아 원격 추적 브랜치를 갱신합니다. 원격 추적 브랜치는 origin/main처럼 원격 상태를 로컬에서 가리키는 표지판입니다. 공식 문서도 fetch가 객체와 참조를 내려받는다고 설명합니다.

fetch만으로 현재 작업 파일이 원격 내용으로 바뀌지는 않습니다. 그래서 차이를 먼저 살펴보는 단계로 쓰기 좋습니다. git status로 작업 트리가 깨끗한지 확인하고 fetch한 뒤 현재 브랜치와 origin/main의 차이를 로그나 비교 화면에서 읽습니다.

• 현재 브랜치 이름을 확인합니다.
• 커밋하지 않은 파일이 있는지 봅니다.
• origin 주소가 기대한 저장소인지 확인합니다.
• fetch 뒤 들어올 커밋 제목을 읽습니다.
• 예상하지 못한 대량 변경이 보이면 합치지 않고 담당자에게 묻습니다.

pull은 가져오기와 합치기를 한 번에 요청한다

git pull은 보통 fetch한 뒤 현재 브랜치에 원격 변경을 통합합니다. 설정에 따라 merge나 rebase 방식이 쓰일 수 있습니다. merge는 두 작업 흐름을 합쳐 기록하고, rebase는 내 커밋의 기반을 옮겨 역사를 다시 배열하는 방식입니다. 뜻을 모른 채 선택하면 공유 이력을 이해하기 어려워질 수 있습니다.

식당 공동 장부에 다른 직원이 적은 주문을 내 장부로 옮기는 순간을 생각해 보세요. 같은 칸을 서로 다르게 고쳤다면 자동으로 하나를 고를 수 없어 충돌이 납니다. pull 전에 로컬 변경을 정리하고 원격 차이를 읽으면 충돌을 피하지 못하더라도 원인을 찾기 쉬워집니다.

push는 로컬 커밋을 원격 브랜치로 보낸다

git push는 내 저장소의 커밋과 관련 객체를 원격 참조로 보냅니다. 가장 단순한 형태는 원격 이름과 브랜치 이름을 함께 쓰는 것입니다. 다만 프로젝트가 main인지 master인지, 별도 기능 브랜치를 쓰는지 먼저 확인해야 합니다.

push는 저장되지 않은 파일을 보내는 명령이 아닙니다. 커밋에 들어간 내용만 보냅니다. 따라서 git status와 git diff로 변경을 검토하고, git log로 보낼 커밋을 확인합니다. .env, 개인키, 고객 자료가 커밋에 들어갔다면 push를 멈춥니다. 커밋에서 파일을 지워도 이전 기록에 비밀이 남을 수 있으므로 노출된 키는 폐기하고 다시 발급해야 합니다.

강제 push는 공유 기록을 덮을 수 있다

force 옵션이 붙은 push는 원격 브랜치가 기대한 선조 관계가 아니어도 갱신을 시도할 수 있습니다. 팀원이 올린 커밋을 보이지 않게 만들 수 있어 초보자가 문제 해결용으로 바로 사용할 명령이 아닙니다. 영상이나 답변에서 강제 push를 권해도 저장소 운영 규칙과 백업, 영향 범위를 모르면 실행하지 않습니다.

push가 거절되면 거절 이유를 먼저 읽습니다. 원격이 앞서 있다면 fetch 후 차이를 비교하고 합치는 방법을 정합니다. 보호 브랜치라면 직접 push 대신 새 브랜치와 pull request가 필요할 수 있습니다. 권한 오류라면 토큰을 채팅에 붙이지 말고 저장소 관리자에게 필요한 권한을 확인합니다.

상태를 네 단어로 나눠 기록한다

혼동을 줄이려면 saved, committed, pushed, deployed를 구분합니다. 파일 저장은 편집기 상태, commit은 로컬 Git 기록, pushed는 원격 반영, deployed는 서비스 서버 반영입니다. push 성공이 곧 공개 사이트 변경이나 배포 성공을 뜻하지 않습니다.

원격 페이지에서 새 커밋이 보이는지 확인하고 자동 배포가 있다면 별도 상태를 봅니다. 공개 주소에서 기능이 바뀌었는지도 다시 확인해야 합니다. 단계마다 증거가 다르므로 한 문장으로 모두 성공했다고 적지 않습니다.

오늘 바로 해볼 작은 실습

공개 연습 저장소나 변경하지 않아도 되는 저장소에서 읽기만 합니다.

1. git status로 현재 브랜치와 변경 파일을 확인합니다.
2. git remote -v로 origin 주소를 읽되 비밀 정보가 있으면 공유하지 않습니다.
3. git fetch origin으로 원격 기록을 받아옵니다.
4. git log --oneline -5로 최근 커밋 제목을 읽습니다.
5. 현재 브랜치와 원격 추적 브랜치가 앞서거나 뒤졌는지 status에서 봅니다.
6. 이번 실습에서는 pull, push, force 옵션을 실행하지 않습니다.

모르는 원격 주소, 비밀키, 결제 코드, 데이터 삭제 변경이 보이면 보내지 않습니다. 공유 브랜치에서 강제 push를 요구하는 상황은 혼자 해결하지 말고 현재 HEAD와 원격 커밋을 보존한 채 검토를 요청하세요. 방향을 구분하는 것만으로도 Git 사고의 상당 부분을 예방할 수 있습니다.