Git: push 거부 — 원격에 없는 커밋이 있어 거절됨 (non-fast-forward)

안녕하세요, BlueByte입니다. git push를 실행했는데 커밋이 올라가는 대신 Git이 ! [rejected] main -> main (fetch first)와, 원격에 당신에게 없는 커밋이 있다는 문단으로 멈춥니다. 깨진 것도, 잃어버린 커밋도 없습니다 — Git이 보이는데 당신에겐 없는 히스토리를 덮어쓰기를 거부하는 것뿐입니다. 증상은 push가 Updates were rejected로 끝나며 거절 줄에 (fetch first)나 (non-fast-forward)가 붙는 것입니다. 오늘은 이 두 변형의 뜻, push가 거부된 이유, 두 히스토리를 안전하게 합치는 법, 재발 예방까지 하나씩 짚어보겠습니다.

"(fetch first)"와 "(non-fast-forward)"가 알려주는 것

전체 거절 메시지는 이렇습니다:

! [rejected]        main -> main (fetch first)
error: failed to push some refs to 'github.com:acme/app.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.

Git은 당신의 브랜치가 원격 브랜치의 곧은 연장선일 때 — fast-forward일 때 — 만 push를 받아들입니다. 원격이 앞서 나가면 당신 커밋은 더 이상 원격 tip의 직계 자손이 아니므로, Git은 원격 커밋을 버리는 대신 거부합니다. 두 힌트 단어가 어느 경우인지 알려줍니다: (fetch first)는 당신 로컬 브랜치가 원격의 새 커밋을 아직 못 봤다는 뜻이고, (non-fast-forward)는 두 히스토리가 실제로 갈라져 양쪽 모두 상대에게 없는 커밋을 가졌다는 뜻입니다.

거부된 push를 만드는 두 상황

non-fast-forward 거절은 다음 중 하나에서 옵니다:

• 마지막 동기화 이후 누군가 push함. 동료나 CI 작업이 같은 브랜치에 커밋을 더했습니다. 당신 히스토리는 틀린 게 아니라 뒤처진 것 — 따라잡으면 됩니다.
• 로컬 히스토리를 다시 씀. git rebase, git commit --amend, git reset이 이미 push한 커밋을 바꿔, 당신 브랜치와 원격이 과거에 대해 서로 어긋납니다.

첫 번째가 흔하며 깔끔한 해결책이 있습니다. 두 번째는 조심해야 합니다 — 안전한 해결과 위험한 해결이 거의 똑같이 생겼기 때문입니다.

손대기 전에 히스토리가 얼마나 갈라졌는지 보기

아직 아무것도 강제하지 마세요 — 먼저 원격 상태를 가져와 간극을 재세요:

git fetch
git status

Your branch and 'origin/main' have diverged,
and have 1 and 2 different commits each, respectively.

이 줄이 진단 전부입니다: 당신에겐 원격에 없는 커밋 1개, 원격엔 당신에게 없는 커밋 2개가 있습니다. 나란히 보려면:

git log --oneline --graph --left-right HEAD...origin/main

< 표시는 당신 커밋, >는 원격 커밋입니다. 모두 >이고 <가 없으면 단순히 뒤처진 것 — 그냥 git pull이 fast-forward합니다. 둘 다 나오면 갈라진 것이라 merge나 rebase를 만들게 됩니다.

흔한 해결: 원격 작업을 먼저 들여오고 push하기

누군가 앞서 push한 일상적 경우엔 그들의 커밋을 가져와 당신 것을 그 위에 얹고 push하세요:

git pull --rebase
git push

Successfully rebased and updated refs/heads/main.
...
To github.com:acme/app.git
   3f2a1b0..9c8d7e6  main -> main

git pull --rebase는 원격 커밋을 가져와 당신 커밋을 그 뒤에 다시 얹으므로 히스토리가 선형으로 남고 push가 이제 fast-forward합니다. 그냥 git pull(merge)도 되지만 merge 커밋이 남습니다. rebase가 충돌을 보고하면 파일을 해결하고 git add한 뒤 git rebase --continue를 실행하세요.

히스토리를 일부러 다시 썼다면: --force-with-lease, 절대 --force는 금물

리뷰 전 지저분한 브랜치를 squash하는 식으로 이미 push한 자기 커밋을 의도적으로 다시 써서 갈라진 경우라면, 그것을 도로 pull하면 정리가 되돌아갑니다. 이때는 원격을 덮어쓰되 안전장치를 두세요:

git push --force-with-lease

--force-with-lease는 원격이 당신이 마지막으로 본 위치를 여전히 가리킬 때만 덮어씁니다 — 그사이 동료가 push했다면 그 커밋을 지우는 대신 push가 실패합니다. 그냥 git push --force는 그 검사를 건너뛰어 남이 push한 작업을 조용히 지울 수 있으니, 매번 --force-with-lease를 쓰고, main 같은 공유 브랜치는 합의 없이 절대 강제하지 마세요.

실제 사례: 작업 중 동료가 push했을 때

수정을 마치고 커밋한 뒤 git push가 (fetch first)와 Updates were rejected because the remote contains work that you do not have로 거부됩니다. git fetch와 git status를 실행하니 브랜치가 1개와 1개로 갈라졌다고 나옵니다. 아무것도 다시 쓰지 않았으니 흔한 경우입니다: git pull --rebase를 실행하면 Git이 당신의 커밋 1개를 동료 커밋 위에 다시 얹고 git push가 성공합니다 — 거절 줄이 사라지고 두 커밋이 순서대로 원격에 올라갑니다.

push가 실제로 도착했는지 확인

로컬과 원격이 일치하는지 확인하세요:

git status

Your branch is up to date with 'origin/main'.
nothing to commit, working tree clean

up to date with 'origin/main'이면 push가 깔끔하게 fast-forward한 것입니다. git log --oneline -3은 원격 커밋과 나란히 당신 커밋을 tip에 보여야 하고, 다음 push에서 (fetch first)가 없어야 합니다.

거부된 push에 놀라지 않으려면

작업을 시작하기 전과 push하기 전에 fetch해서 원격보다 뒤처지는 일을 줄이세요. git config --global pull.rebase true를 설정하면 git pull이 기본으로 rebase해 merge 커밋을 흩뿌리지 않고 선형 히스토리를 지킵니다. 공유 브랜치에는 직접 push보다 pull request를 쓰고, 히스토리를 다시 써야 한다면 동료 작업을 덮지 않도록 항상 --force-with-lease를 쓰세요. 하루 일과 끝에 한 번 크게 push하기보다 작게 자주 push할수록 덜 갈라집니다.

protected-branch나 "src refspec" 거절과의 차이

non-fast-forward 거절은 히스토리 모양의 문제입니다 — 당신 브랜치가 원격의 자손이 아니고, fetch로 풀립니다. 비슷해 보이는 다른 두 거절은 그렇지 않습니다: protected branch hook declined나 GH006은 히스토리와 무관하게 서버 정책이 push를 막는 것 — pull request가 필요하고 아무리 pull해도 소용없습니다. error: src refspec main does not match any는 브랜치가 로컬에 아예 없다는 뜻 — 대개 오타이거나 아직 아무것도 커밋 안 한 빈 저장소입니다. 메시지가 "remote contains work"가 아니라 hook이나 refspec을 가리키면 non-fast-forward가 아니고 git pull로 고쳐지지 않습니다.