git push 에러(rejected) 해결하는 법: 원인별 완벽 정리

git push 에러(rejected), 왜 거부될까

git push 에러 중 가장 흔한 것이 ! [rejected] 메시지입니다. 거의 대부분 원인은 하나입니다. 원격 저장소(GitHub)에 내가 갖고 있지 않은 새 커밋이 있어서 Git이 내 push를 막은 것입니다. 누군가 먼저 push했거나, 웹에서 파일을 수정한 경우죠. 이 글에서는 git push rejected 에러를 원인별로 정확히 해결하는 법을 안내합니다.

증상: 이런 메시지가 뜹니다

! [rejected]        main -> main (fetch first)
error: failed to push some refs to 'github.com:user/repo.git'
hint: Updates were rejected because the remote contains work that you do not have locally.

원인 1: 원격에 내가 없는 커밋이 있음 (가장 흔함)

해결책은 원격 변경을 먼저 받아 합친 뒤 다시 push하는 것입니다.

# 원격 변경을 받아서 내 작업과 합치기
git pull origin main

# 충돌이 없으면 바로 push
git push origin main

pull 도중 충돌이 나면 충돌 부분을 해결하고 git add → git commit 후 다시 push하세요.

merge 커밋이 생기는 게 싫다면 rebase로

git pull --rebase origin main
git push origin main

rebase는 내 커밋을 원격 커밋 위로 깔끔하게 재배치해 불필요한 merge 커밋을 만들지 않습니다.

원인 2: 첫 push인데 업스트림이 없음

새 브랜치를 처음 push할 때 나오는 메시지입니다.

fatal: The current branch feature has no upstream branch.

업스트림을 지정하며 push하면 됩니다.

git push -u origin feature

-u(=--set-upstream)를 한 번 붙여두면 이후엔 git push만 입력해도 됩니다.

원인 3: 강제 push가 필요한 경우 (주의)

rebase나 amend로 히스토리를 다시 썼다면 일반 push가 거부됩니다. 이때만 강제 push를 씁니다.

git push --force-with-lease origin feature

경고: --force는 다른 사람의 커밋을 덮어써 버릴 수 있습니다. 반드시 --force-with-lease를 쓰세요. 이건 "내가 마지막으로 본 원격 상태가 그대로일 때만" 덮어쓰므로 협업자의 작업 유실을 막아줍니다. main 같은 공유 브랜치에는 강제 push 금지가 원칙입니다.

원인별 해결 요약

주의점 정리

• rejected는 거의 항상 "먼저 pull 하라"는 신호입니다
• 강제 push 전 협업자에게 반드시 확인
• Permission denied(403)는 push 거부와 다른 인증 문제이니 토큰 설정을 점검하세요

자주 묻는 질문

Q1. git pull을 했더니 충돌이 났어요. 어떻게 하나요?

충돌난 파일을 열어 충돌 기호(<<<, ===, >>>)를 정리한 뒤 git add → git commit(또는 rebase 중이면 git rebase --continue)을 하면 됩니다. 그다음 다시 push하세요.

Q2. --force와 --force-with-lease 중 무엇을 써야 하나요?

항상 --force-with-lease를 권합니다. --force는 그 사이 다른 사람이 push한 커밋도 무조건 덮어쓰지만, --force-with-lease는 원격이 내가 본 상태와 다르면 거부해 사고를 막습니다.

Q3. pull 없이 push만 성공시키는 방법은 없나요?

원격에 새 커밋이 있는 한 정상적인 방법으로는 불가능합니다. 그 커밋을 무시하고 강제로 덮어쓰면 다른 사람의 작업이 사라지므로 매우 위험합니다. 정석대로 pull로 합친 뒤 push하는 것이 안전합니다.