[초급] Git push rejected non-fast-forward? 이 명령어 한 줄이면 5초컷

이 에러는 당신의 로컬 저장소와 원격 저장소의 역사가 서로 달라졌다는 신호다.

자동화 스크립트 하나 고치고 푸시하려는데 이 붉은 글씨가 터졌다. 'git push rejected non-fast-forward'. 피곤한데 진짜 짜증 나는 순간임. 쉽게 말해, 내가 로컬에서 작업하는 동안 다른 누군가, 혹은 다른 시스템이 원격 저장소(origin)에 먼저 새로운 커밋을 밀어 넣은 상태다. 기차로 비유하면, 내 기차(로컬)가 출발하기 전에 이미 저쪽(원격)에서 다른 노선이 깔려버린 것과 같다. 두 노선이 합쳐질 수 없는 상태, 이게 바로 ‘non-fast-forward’의 본질이다.

초심자 열에 아홉은 여기서 `git pull` 부터 누른다. 최악의 선택이다.

아무 생각 없이 `git pull`을 실행하면, 원격 저장소의 변경사항과 내 로컬 변경사항을 합치는 ‘Merge Commit’이라는 못생긴 이정표가 생긴다. 프로젝트 히스토리가 지저분해지는 지름길임. 물론 협업 시에는 `pull` 받아서 충돌을 해결하는 게 맞다. 하지만 혼자 관리하는 개인 프로젝트나, 원격 저장소의 마지막 커밋이 실수였다는 확신이 들 땐 더 깔끔한 방법이 있다.

이럴 땐 그냥 강제로 밀어 넣어라.

내 로컬 작업물이 무조건 맞고, 원격 저장소의 변경사항은 무시해도 될 때 쓰는 명령어다. 이걸로 해결 안 된 적 없다.

# 현재 브랜치(예: main)를 강제로 푸시
git push origin main –force

# 더 짧게 쓰고 싶으면 ‘+’ 기호를 쓴다. 같은 기능임.
git push origin +main

⚠️ 경고: 이 명령어는 굉장히 파괴적이다. ‘내 로컬 버전이 무조건 정답이니, 원격 저장소는 닥치고 내 걸로 덮어써’ 라는 뜻이다. 팀원과 함께 쓰는 공용 브랜치에 이걸 날리는 순간, 그 팀원의 작업물은 허공으로 사라진다. 말 그대로 ‘역사’를 지워버리는 행위임. 개인 브랜치나 혼자 관리하는 프로젝트에서만 써야 한다.

초급자가 흔히 저지르는 실수 3가지

1. 원인도 모르고 `git pull` 부터 받기

문제점: 위에서 말했듯 불필요한 병합 커밋(merge commit)이 생겨서 로그가 더러워진다. 나중에 특정 변경사항을 추적할 때 머리 아파짐.
해결책: 푸시하기 전에 `git fetch` 명령으로 원격 저장소의 최신 내역만 조용히 가져와서 `git log origin/main`으로 뭐가 바뀌었는지 먼저 눈으로 확인하는 습관을 들여야 한다. 상황 파악이 우선이다.

2. `main`이나 `master` 같은 공용 브랜치에 `–force` 남발하기

문제점: 팀원이 푸시해 둔 작업물을 그대로 덮어써서 날려버린다. 인간관계와 프로젝트 모두 파탄 나는 지름길이다.
해결책: 협업 브랜치에서는 `–force` 옵션은 봉인해야 한다. 정 써야겠다면, `git push –force-with-lease`를 쓰는 게 조금 더 안전하다. 이건 최소한 원격 브랜치가 내가 마지막으로 본 상태 그대로일 때만 강제 푸시를 허용해준다. 그 사이에 누가 다른 걸 푸시했다면 실패함.

3. 강제 푸시 전에 백업 안 하기

문제점: 강제 푸시를 했는데, 알고 보니 로컬 작업물이 아니라 원격에 있던 내용이 맞는 거였다. 이미 덮어쓴 후엔 되돌리기 매우 까다롭다.
해결책: 중요한 변경사항을 강제로 밀어 넣기 전에는, 만약을 대비해 현재 상태를 다른 브랜치로 하나 복사해두는 게 좋다. `git branch backup-yyyy-mm-dd` 같은 간단한 명령 하나면 5초 안에 보험을 들 수 있다.

결론: `non-fast-forward` 에러는 Git이 당신의 데이터를 보호하기 위해 보내는 마지막 경고 신호다. 이 신호를 무시하고 `–force`를 남발하기 전에, 원격 저장소에 무슨 일이 있었는지 확인하는 습관부터 들이는 게 엔지니어의 기본 소양이다.

PipeMaster-Lab 운영정책 및 제보 안내