깃허브 푸시 안될때, error: failed to push some refs to

# 깃허브 히스토리 문제일 경우

"error: failed to push some refs to" 뜨면서 로컬 환경에서 깃허브로 commit 하려고 할 때 에러가 발생했다면, 기존 히스토리 문제일 가능성이 있다. 기존 히스토리 문제라는 건 이전에 커밋을 요청했던 작업에 문제가 있는데 컴퓨터가 여기에서 머무르고 계속 문제가 있다고 알리는 상황인 셈이다. 짜증 나는 점은 알아서 새롭게 수정된 버전을 인지하고 새로운 명령어에만 반응하면 되는데, 기존 에러가 발생했던 커밋 명령이 히스토리에 남아있어서 계속 멈춰있는 것이다.

 

예를 들어서, 깃허브에 큰 파일, 즉 대용량 이미지나 파일 저장이 제한적인데 깜빡하고 대용량 이미지 또는 파일이 포함된채 커밋을 요청하면 당연히 이 부분에서 Push가 fail 된다. 그러고 해당 파일이나 이미지를 삭제하고 다시 시도를 하려고 해도 이미 없는 파일에 대해서 자꾸 있다고 하면서 커밋은 되지만 push가 안 되는 것이다.

 

이런 경우, 히스토리에서 문제가 되었던 부분을 정리하고 다시 커밋을 요청해야한다. 한마디로 컴퓨터에게 잘못된 부분을 정리하고 다시 요청만 하는 게 아니라, 요청했던 명령조차도 수정한 다음에 다시 요청을 진행해야 한다는 것이다. 결과적으로 세부적으로 히스토리에 들어가서 수정할 거 아니면 force로 커밋과 push를 다시하는게 가장 편하다.

---

# 원격 origin -> 강제 Push

강제 Push를 진행하고 나면 기존의 커밋 요청을 했던 히스토리를 무시하고 진행이 되기 때문에 자동으로 기존 히스토리가 삭제되는 셈이다. 한마디로 하나의 문제점에 사로잡혀있는 컴퓨터를 강제로 끌고 원래의 목적에 도달하도록 만드는 셈이다. 먼저 다시 remote로 repository를 지정해주고 나서 강제 push를 하는 것이 또 다른 문제의 경우를 없앨 수 있기에 아래의 방법을 추천한다.

---

git remote -v

git remote add origin [repository 도메인].git

git push --force --all origin

---

위의 방법을 통해 기존 히스토리 커밋 에러와 상관없이 커밋과 Push가 완료되는 걸 확인할 수 있다. 만약 매번 특정 파일이나 특정 상황에 대해 커밋 에러를 ignore해야하는 경우에는 gitignore를 사용하는 것이 좋다. 하지만 그게 아니라 여러 번의 히스토리 커밋 에러 때문에 복잡하게 꼬여있는 상황이라면 위와 같은 방법으로 한 번에 정리가 가능하고 에러를 해결할 수가 있다.

---