커밋을 github에 푸시하면 Git이 실패합니다.


130

github에서 호스팅 한 git repo를 랩톱에 복제했습니다. 문제없이 몇 가지 커밋을 github에 성공적으로 푸시 할 수있었습니다. 그러나 이제 다음 오류가 발생합니다.

Compressing objects: 100% (792/792), done.
error: RPC failed; result=22, HTTP code = 411
Writing objects: 100% (1148/1148), 18.79 MiB | 13.81 MiB/s, done.
Total 1148 (delta 356), reused 944 (delta 214)

여기에서 그것은 단지 중지와 나는 마지막으로이 CTRL+ C단자 다시.


왜 HTTP 오류가 있습니까? SSH를 통해 github에 푸시하지 않습니까?
— Cascabel

명확히하기 위해 : origin섹션의 URL .git/config이 http라고 말하지 않습니까?
— Cascabel

@Jefromi 읽기 / 쓰기 http 링크를 사용하여 개인 저장소를 복제했습니다.
— Stephen Melvin

아니요, https라고 말합니다. 내가 실패하기 전에 두 번의 푸시를 할 수 있었기 때문에 이상합니다.
— Stephen Melvin

답변:


292

나는 같은 문제를 겪었고 푸시하려는 repo의 크기 (특정 파일의 크기 또는 편집 된 크기)와 관련이 있다고 생각합니다.

기본적으로 새로운 저장소를 만들고 github에 푸시 할 수있었습니다. 그러나 기존 제품은 작동하지 않습니다.

HTTP 오류 코드가 '길이가 필요합니다'오류 인 것을 백업하는 것 같습니다. 따라서 최대 값을 계산하거나 계산하기에는 너무 큽니다. 누가 알아.

편집하다

문제가 큰 파일이라는 것을 알았습니다. 그 시점까지 성공적으로 푸시했지만 푸시하지 않는 업데이트가 하나있었습니다. 커밋에 파일이 하나만 있었지만 1.6M이었습니다.

그래서 다음 구성 변경을 추가했습니다.

git config http.postBuffer 524288000

파일 크기 500M까지 허용 한 다음 푸시가 작동했습니다. http 프로토콜에 대해 큰 repo를 푸시하면 처음에는 이것이 문제 일 수 있습니다.

편집 종료

내가 그것을 작동시킬 수있는 방법 (postBuffer를 수정하기 전에 편집)은 repo를 압축하고 ssh를 통해 git을 수행 할 수있는 시스템에 복사하고 github으로 푸시하는 것이 었습니다. 그런 다음 원래 서버에서 푸시 / 풀을 시도하면 https를 통해 작동해야합니다. (원래 푸시보다 훨씬 적은 양의 데이터이므로).

도움이 되었기를 바랍니다.


411 대신 HTTP 501 오류가 있었지만 나에게도 도움이되었습니다. 감사합니다!
— Emaad Ahmed Manzoor

감사! 이것은 효과가 있었고 심지어 업로드 속도를 높였습니다. 웹 사이트를 새로운 Windows Azure 웹 사이트로 푸시하려고했지만 계속 실패했습니다.
— Jake

23
이 값을 매우 높게 설정하면 단점이 있습니까?
— snogglethorpe 2019

@snogglethorpe 잠재적으로 : "전송 인코딩 : 청크 분할은 대량 팩 파일을 로컬로 작성하지 않도록하기 위해 사용됩니다." 값을 큰 것으로 설정하면 푸시하려고 할 때 대량 팩 파일이 생성 될 수 있습니다. 모든 파일 시스템이 대용량 파일을 제대로 처리하지는 않으며 효율적으로 정리하지 못할 수 있습니다. 이 파일들은 .git / objects / pack에서 볼 수 있습니다.
— hemp

를 변경하는 http.postBuffer것은 유해한 것 보다 불필요 하지만 부작용이 있습니다. 기본값보다 높이면 클라이언트가 HTTP 요청을 더 큰 청크로 버퍼링하므로 더 큰 푸시에 대한 대기 시간이 증가 할 수 있습니다.
— Swatantra Kumar

8

이 명령이 도움이되지 않으면

자식 설정 http.postBuffer 524288000

ssh 방법을 https로 변경하십시오.

git remote -v
git remote rm origin 
git remote add origin https://github.com/username/project.git

4

서버 문제 (예 : "GitHub"문제)처럼 보입니다.
당신이 보면 이 스레드 (가) 때 일어날 수있는 git-http-backend손상된 힙을 가져옵니다. (그들은 이후 단지 장소에 넣어 스마트 HTTP 지원을 ...)
하지만, 실제 원인이 무엇이든, 그것은 또한 최근과 관련이있을 수 있습니다 에서 산발적 중단 GitHub 파일 서버 중 하나입니다 .

이 오류 메시지가 계속 나타 납니까? 당신이 할 경우 :

  • 로컬 Git 버전을 확인하고 최신 버전으로 업그레이드하십시오.
  • 이것을 GitHub 버그 로보고하십시오 .

참고 : 스마트 HTTP 지원 은 인증 된 엔터프라이즈 방화벽 프록시를 사용하는 사람들에게 큰 도움이됩니다!

이제부터 http://URL을 통해 저장소를 복제하고 Git 클라이언트 버전 1.6.6 이상을 사용하는 경우 Git은 더 새롭고 더 나은 전송 메커니즘을 자동으로 사용합니다.
그러나 더 놀라운 것은 이제 해당 프로토콜을 넘겨 개인 저장소를 복제 할 수 있다는 것입니다. 개인 저장소에 액세스하거나 공동 작업자이고 푸시 액세스를 원하는 경우 사용자 이름을 URL에 입력하면 Git에서 액세스하려고 할 때 암호를 묻는 메시지를 표시합니다.

더 오래된 고객은 더 오래되고 덜 효율적인 방법으로 돌아가므로 아무 것도 깨지 않아야합니다. 새로운 고객 만 더 잘 작동해야합니다.

다시 한번, Git 클라이언트를 먼저 업그레이드하십시오.


ADSL 무선 라우터 (French Orange Livebox)와 비슷한 문제가 발생했습니다 : github.com 에서 SSH 키를 게시 할 수 없으며 https를 밀어 넣습니다. 대체 인터넷 액세스를 사용할 때까지.
— Yves Martin

푸시하려고 할 때 "오류 : RPC 실패; 결과 = 22, HTTP 코드 = 0"이 표시 될 때 Smart HTTP Support가 방화벽 프록시를 통해 나를 안내했습니다.
— Boggin 2016 년

@Boggin 예, 스마트 http가 프록시 뒤에있을 때 일반적으로 선호되는 선택임을 확인합니다. 표준 http / https 포트는 (거의) 항상 열려 있습니다.
— VonC 2016 년


0

나는 자신의 호스팅 된 bonobo-git 서버에 푸시하려고 시도했지만 http.postbuffer가 프로젝트 디렉토리를 의미한다는 것을 깨닫지 못했습니다 ...

다른 혼란스러운 사람들을 위해 :

왜? 내 경우에는 자산이 포함 된 큰 zip 파일과 일부 PSD도 밀어 넣었습니다.

이 http.postbuffer를 수행하는 방법 : 서버가 아닌 .git 폴더 옆의 프로젝트 src 디렉토리에서 해당 명령을 실행하십시오.

이 버퍼 크기로 큰 임시 (청크) 파일이 생성됩니다.

참고 : 가장 큰 파일을 확인한 다음 버퍼를 설정하십시오.


-2

주로 푸시해야하는 문제는 푸시해야하는 파일 크기 때문입니다. 크기가 2MB 인 일부 라이브러리를 푸시하려고했지만 푸시도 결과 7의 RPC 오류를 발생 시켰습니다. 라인은 4mbps이며 정상적으로 작동합니다. 그 이후의 시도는 성공을 거두었습니다. 이러한 오류가 발생하면 몇 분 정도 기다렸다가 계속 시도하십시오.

또한 github이 다운되었거나 측면에서 불안정한 네트워크를 얻는 경우 일부 RPC 오류가 있음을 알았습니다.

따라서 일정한 간격 후에 시도하는 것이 유일한 옵션입니다!


-2

이 경우 https가 붙어 있으면 ssh를 시도 할 수 있습니다.

또한 버퍼 크기를 천문학적 수치로 늘려서 더 이상 버퍼 크기에 대해 걱정할 필요가 없습니다 .git config http.postBuffer 100000000

당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.