커밋을 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.