Git push 거절된 코딩 초보가 3분 만에 확인할 5가지

GitHub에 코드를 올리려고 git push를 눌렀는데 rejected, non-fast-forward, failed to push some refs가 나오면 초보자는 두 가지를 동시에 걱정합니다. 내 코드가 사라진 건지, 아니면 내가 뭔가 크게 망가뜨린 건지 판단이 안 됩니다. 이때 바로 git push --force를 검색해서 따라 치면 더 위험합니다. 먼저 3분만 쓰면 AI에게도 훨씬 정확하게 물어볼 수 있습니다.

Tap to zoom

docs.github.com의 non-fast-forward 안내는 원격 저장소의 커밋을 잃게 만들 수 있는 push를 Git이 거절한다고 설명합니다. git-scm.com의 git push 문서도 강제로 non-fast-forward 업데이트를 허용하면 기존 원격 커밋이 브랜치에서 떨어져 나갈 수 있다고 설명합니다. 그래서 이 오류는 단순 실패가 아니라, 원격에 있는 작업을 덮어쓰지 말라는 멈춤 신호에 가깝습니다.

1분째에는 에러 원문에서 뒤처진 브랜치를 찾습니다

먼저 터미널의 마지막 줄만 보지 않습니다. failed to push some refs는 결과 문장입니다. 실제 힌트는 그 위에 있습니다. 아래와 비슷한 문구가 있으면 원격 브랜치에 내가 아직 받지 않은 커밋이 있다는 뜻으로 봅니다.

! [rejected] main -> main (non-fast-forward)
error: failed to push some refs to ...
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart.

초보자가 여기서 해야 할 일은 원인 해석보다 보존입니다. 지금 브랜치 이름, 원격 이름, 거절된 대상 브랜치를 적어 둡니다. main -> main이면 내 로컬 main을 원격 main에 올리려다 막힌 상태입니다. feature/login -> feature/login이면 기능 브랜치에서 막힌 상태입니다.

AI에게 물을 때도 이 줄을 그대로 줍니다. "push가 안 돼"보다 "main -> main non-fast-forward가 떴다"가 훨씬 낫습니다. OpenAI Help Center의 프롬프트 작성 안내도 원하는 맥락과 결과 형식을 구체적으로 쓰라고 설명합니다. Git 오류 질문도 같은 방식으로 에러 원문과 원하는 행동을 분리해야 합니다.

2분째에는 내 작업이 저장됐는지 먼저 확인합니다

push가 거절됐다고 해서 내 파일이 사라진 것은 아닙니다. 다만 다음 명령을 치기 전에 내 작업 상태를 확인해야 합니다.

git status

여기서 nothing to commit, working tree clean이면 커밋까지 된 상태일 가능성이 큽니다. 수정 파일이 남아 있으면 아직 커밋하지 않은 변경이 있다는 뜻입니다. 이 상태에서 무작정 pull이나 rebase를 하면 충돌을 만났을 때 초보자가 더 헷갈릴 수 있습니다.

확인 순서는 짧게 잡습니다.

1. git status로 수정 파일이 남았는지 봅니다.
2. 남아 있다면 필요한 파일을 커밋하거나 임시 보관합니다.
3. 커밋한 뒤 다시 git status를 봅니다.
4. 브랜치 이름을 확인합니다.

아직 Git이 익숙하지 않다면 git stash까지 바로 가지 않아도 됩니다. 먼저 바뀐 파일 이름을 메모하고, 에디터에서 중요한 코드를 확인합니다. AI에게도 "아직 커밋하지 않은 파일이 있다"는 사실을 알려야 합니다.

3분째에는 fetch로 원격 변경을 먼저 가져옵니다

바로 git pull을 치기 전에 원격에 무엇이 생겼는지 분리해서 보는 편이 안전합니다.

git fetch origin

fetch는 원격 정보를 가져오지만 내 작업 브랜치를 바로 섞지 않습니다. 그래서 초보자가 현재 상태를 잃지 않고 다음 판단을 할 수 있습니다. 그다음 브랜치 차이를 확인합니다.

git log --oneline --decorate --graph --all -n 12

그래프가 어렵다면 AI에게 이 출력 일부를 붙여도 됩니다. 중요한 것은 "원격에 새 커밋이 있다"와 "내 로컬에도 새 커밋이 있다"를 구분하는 일입니다. 원격만 앞서 있으면 가져와서 합치면 됩니다. 양쪽에 서로 다른 커밋이 있으면 충돌 가능성을 생각해야 합니다.

이 단계에서 --force는 아직 선택지가 아닙니다. Git 문서가 경고하는 손실은 바로 이 지점에서 생길 수 있습니다. 내가 원격에 없는 커밋을 밀어 넣는 과정에서 원격의 다른 커밋을 지울 수 있기 때문입니다.

AI에게는 해결 명령보다 판단 자료를 먼저 줍니다

AI에게 "명령어 알려줘"라고만 쓰면 위험한 답이 나올 수 있습니다. 지금 필요한 것은 무조건 실행할 명령이 아니라, 내 상황에서 안전한 다음 한 단계를 고르는 일입니다.

Tap to zoom

아래 프롬프트를 그대로 채워 넣습니다.

상황:
GitHub에 push하려고 했는데 non-fast-forward로 거절됐습니다.

에러 원문:
[터미널의 rejected 줄과 hint 줄을 붙여 넣기]

현재 상태:
[git status 결과를 붙여 넣기]

브랜치:
현재 브랜치: [브랜치명]
push 대상: [예: origin main]

최근 확인:
git fetch origin은 실행했습니다.
git log --oneline --decorate --graph --all -n 12 결과는 아래와 같습니다.
[출력 붙여 넣기]

요청:
내 로컬 변경을 잃지 않는 방향으로 원인을 3가지 안에서 좁혀 주세요.
바로 실행할 명령은 한 번에 하나만 제안해 주세요.
force push가 필요하다고 판단하면 왜 필요한지와 먼저 확인할 위험을 설명해 주세요.

이 프롬프트의 핵심은 마지막 세 줄입니다. AI에게 한 번에 모든 명령을 실행하라고 하지 않고, 위험한 명령에는 근거 설명을 요구합니다. OpenAI Help Center의 ChatGPT 프롬프트 안내도 명확하고 구체적인 요청, 반복 개선을 권합니다. Git 오류는 한 번에 맞히는 문제보다 상태를 줄여 가는 문제에 가깝습니다.

합칠 때는 팀 규칙이 없으면 merge부터 묻습니다

원격 변경을 내 브랜치에 반영하는 방식은 보통 merge 또는 rebase입니다. 팀이나 수업에서 정한 방식이 있으면 그 규칙을 따릅니다. 규칙이 없다면 초보자는 AI에게 먼저 이렇게 물어보는 편이 낫습니다.

이 저장소에서 merge와 rebase 중 무엇이 더 안전한지 판단해 주세요.
저는 Git 초보이고, 원격 커밋을 덮어쓰면 안 됩니다.
팀 규칙은 아직 모릅니다.

혼자 쓰는 연습 저장소라면 단순히 원격 변경을 받아 합친 뒤 다시 push하는 흐름으로 해결될 수 있습니다. 협업 저장소라면 다릅니다. 같은 브랜치에 다른 사람이 올린 커밋이 있으면, 내 판단만으로 history를 바꾸는 명령을 치면 안 됩니다.

초보자 기준의 안전한 멈춤 기준은 분명합니다.

1. --force 또는 --force-with-lease가 답으로 나오면 바로 실행하지 않습니다.
2. main, master, production 같은 공유 브랜치면 강사나 팀원에게 확인합니다.
3. 충돌 파일이 나오면 AI에게 충돌 파일명과 충돌 부분만 붙여 넣습니다.
4. 해결 후에는 git status가 깨끗한지 다시 확인합니다.

다시 push하기 전에는 바뀐 기록을 한 번만 확인합니다

원격 변경을 반영하고 충돌까지 정리했다면 마지막으로 현재 브랜치와 로그를 확인합니다.

git status
git log --oneline --decorate -n 5

그다음 push합니다.

git push origin main

브랜치 이름이 main이 아니라면 현재 브랜치에 맞게 바꿉니다. 여기서 성공하면 문제는 끝입니다. 실패 메시지가 바뀌었다면 같은 질문을 반복하지 말고 새 에러 원문을 기준으로 다시 묻습니다. "아직 안 돼"가 아니라 "에러가 non-fast-forward에서 인증 오류로 바뀌었다"처럼 말해야 다음 답이 정확해집니다.

오늘 이 오류를 만났다면 해결보다 먼저 멈춤 순서를 기억하면 됩니다. 에러 원문, git status, git fetch origin, 최근 로그, 보존할 파일입니다. 이 다섯 가지를 모은 뒤 AI에게 물으면 Git을 잘 모르는 상태에서도 내 작업을 잃을 가능성을 줄일 수 있습니다.

참고 출처

• GitHub Docs, Dealing with non-fast-forward errors: https://docs.github.com/en/get-started/using-git/dealing-with-non-fast-forward-errors
• Git Documentation, git-push: https://git-scm.com/docs/git-push
• OpenAI Help Center, Best practices for prompt engineering with the OpenAI API: https://help.openai.com/en/articles/6654000-best-practices-for-prompt-engineering-with-openai-api
• OpenAI Help Center, Prompt engineering best practices for ChatGPT: https://help.openai.com/en/articles/10032626-prompt-engineering-best-practices-for-chatgpt