Git, 치명적:원격 끝이 예기치 않게 끊어졌습니다.
내가 도망치려고 했을 때
git push origin master --force
방금 받았어요
Counting objects: 2649, done.
Delta compression uses up to 2 threads.
Compressing objects: 100% (1280/1280), done.
error: RPC failed; result=22, HTTP code = 413 | 116 KiB/s
fatal: The remote end hung up unexpectedly
Writing objects: 100% (2504/2504), 449.61 MiB | 4.19 MiB/s, done.
Total 2504 (delta 1309), reused 2242 (delta 1216)
fatal: The remote end hung up unexpectedly
Everything up-to-date
안전하지 않은 것과 관련이 있습니까?Fatal:에 대한 답변으로 공용 키를 생성하려고 했습니다. 원격 엔드가 예기치 않게 전화를 끊고 다시 실행했지만 여전히 작동하지 않습니다.제가 실제로 키를 사용하지 않는 건가요?그렇다면 어떻게 사용해야 하나요?
이는 git/https 버퍼 설정 때문입니다.
실행: (커밋을 github에 푸시할 때 Git에서 가져온 실패)
git config http.postBuffer 524288000
그런 다음 원래 명령을 다시 실행합니다.
원인: Git의 기본 파일 게시 크기를 초과했습니다.
솔루션:repo로 이동합니다.저장소로 이동한 후 다음 명령을 실행하여 버퍼를 500MB로 늘립니다.
git config http.postBuffer 524288000
이것은 새 리포지토리의 경우 https가 아닌 ssh로 기본값으로 허브를 가져오는 방법과 유사합니다.아마도 http 프로토콜에서 ssh로 전환해 볼 가치가 있을 것입니다.
$ git remote add origin git@github.com:username/project.git
다음과 같은 오류가 발생할 수 있습니다.
오류: 구성 파일 .git/config를 잠글 수 없습니다.해당 파일 또는 디렉터리가 없습니다.
그것은 당신이 현지인이 없기 때문입니다..git/config파일 다음 명령을 사용하여 작동할 수 있습니다.
git config --global http.postBuffer 524288000
범인(내 경우):
대기 시간이 긴 네트워크입니다.
이것은 답 그 자체가 아니라 다른 사람들에게 도움이 될 수도 있는 관찰에 가깝습니다.대기 시간이 긴 네트워크에서 이 오류가 가끔 나타납니다(예: 인터넷 액세스를 위해 위성 디스크를 사용해야 함).네트워크 속도는 괜찮지만 대기 시간이 높을 수 있습니다.참고: 특정 시나리오에서만 문제가 발생하지만 패턴이 무엇인지는 확인하지 못했습니다.
임시 완화:
네트워크를 전환하여 더 느리지만 지연 시간이 짧은 셀 네트워크(전화기를 핫스팟으로 사용)로 이동했더니 문제가 사라졌습니다.셀 연결도 간헐적이기 때문에 이 작업은 일시적으로만 수행할 수 있습니다.게다가 대역폭 사용은 비용을 증가시킵니다.이 옵션을 사용할 수 있다는 것도 행운입니다.모두가 그렇지는 않습니다.
Git 또는 ssh 또는 curl 또는 시간 초과가 먼저 발생하는 경우 이러한 네트워크에 대해 더 많은 내성을 갖게 하는 구성 설정이 있을 것입니다. 하지만 그게 무엇인지는 모르겠습니다.
개발자들에게 보내는 탄원서:
이런 종류의 문제들은 농촌 인구들에게 지속적인 문제입니다.시스템, 툴 및 애플리케이션을 설계할 때 당사를 고려해 주십시오.감사해요.
다른 솔루션은 제 경우에는 작동하지 않았습니다. 가비지 컬렉션을 통해 해결했습니다.
git gc --aggressive
로 시도할수있습니다.git gc
다른 답변 중 하나와 반대로 - ssh를 사용하여 푸시할 때 문제가 발생했습니다 - https로 전환했고 수정되었습니다.
git remote remove origin
git remote add origin https://github.com/user/repo
git push --set-upstream origin master
GitHub를 사용하는 경우, repo의 디렉토리에서 다음 명령을 실행하여 GitHub의 최대 허용 값으로 표시되는 값을 설정합니다.
git config http.postBuffer 2147483648
대신복사용경우는을 사용하여 git clone동일한 옵션으로 복제할 수 있습니다.
git clone -c http.postBuffer=2147483648 git@github.com:myuser/myrepo.git /path/to/myrepo
두 경우 모두 위의 숫자는 2Gb에 해당합니다.그러나 이 값을 사용하려면 이 정도의 여유 메모리가 필요할 수 있습니다.
GitHub에 푸시할 때마다 이 크기 이상의 변경 사항을 추가하지 않는 커밋이 있는지 확인합니다.사실 저는 안전을 위해 커밋 푸시 크기를 1.8 GiB 미만으로 유지할 것입니다.이 경우 큰 커밋을 작은 커밋과 푸시로 분할해야 할 수 있습니다.
왜 이 가치가 있을까요?
이 특정 값은 적어도 2018년 현재 이 값이 GitHub의 푸시 크기 제한으로 문서화되었기 때문에 사용됩니다.
2GB 이상의 푸시는 허용되지 않습니다.
더 낮게 설정하는 게 어때요?
일부 이전 답변에서는 524288000(500MiB)으로 설정하도록 되어 있지만, 이 숫자는 임의적이고 가치가 없어 보입니다.푸시 크기가 설정된 값보다 크지 않은 한 낮은 값이 작동해야 합니다.
더 높게 설정하는 게 어때요?
대신 값을 2Gb보다 높게 설정하고 시도한 푸시 크기도 더 큰 경우 GitHub에서 문서화된 오류를 예상할 수 있습니다.
원격: 치명적: 팩이 허용된 최대 크기를 초과합니다.
다음 명령은 도움이 될 수 있습니다.
git config --global http.postBuffer 1048576000
git config --global http.lowSpeedLimit 0
git config --global http.lowSpeedTime 999999
이 오류는 리포지토리에 대한 쓰기 권한이 누락된 경우에도 발생할 수 있습니다.
제 구체적인 사례는 다음과 같습니다.
- 다음을 사용하여 레포를 작성했습니다.
root내 서버의 사용자(SSH를 통해). - Git 서비스를 설치하고 다음을 만들었습니다.
git모든 Git 관련 작업을 관리해야 하는 Linux 사용자. - 그 무렵, 저는 레포가 다음과 함께 만들어졌다는 것을 잊고 있었습니다.
root에초사자용그, 고리애.git사용자는 저장소에 아무것도 쓸 수 있는 파일 권한이 없었습니다.
레포에 푸시하기 위해 사용 중인 프로토콜을 기반으로 합니다.
HTTP
git config --global http.postBuffer 157286400
참조:
SSH
다을추가다합에 다음을 합니다.~/.ssh/config의 파일
Host your-gitlab-server.com
ServerAliveInterval 60
ServerAliveCountMax 5
IPQoS throughput
참조:
- https://docs.gitlab.com/ee/topics/git/troubleshooting_git.html#check-your-ssh-configuration
- https://unix.stackexchange.com/questions/3026/what-options-serveraliveinterval-and-clientaliveinterval-in-sshd-config-exac
- https://communities.vmware.com/message/2778248
이 글은 설명이 아주 잘 되어 있어서 저의 고민을 해결해 주었습니다.
git config --global http.postBuffer 157286400
우리의 경우, 문제는 다음과 같은 내용을 쓴 복제품이었습니다..git/config읽기 전용 액세스 방법인 URL 항목이 포함된 파일입니다.에 URL URL ://에서 에한방까지.@방법이 문제를 해결했습니다.
중입니다.git remote -v이슈를 좀 조명했습니다.
사후 버퍼를 구성한 후에도 문제가 해결되지 않았습니다.
와이파이 네트워크를 광대역에서 모바일 핫스팟으로 변경했을 때 문제가 해결되었습니다.이것은 논리적으로 정답이 아닐 수도 있지만 문제를 해결했습니다.
인터넷 속도가 좋은지 확인합니다.
위의 해결책들 중 어느 것도 저에게 효과가 없었지만, 제가 추진하고 있는 약속은 매우 컸습니다.
아주 간단하게, 저는 그것을 두 개의 커밋으로 나누고 각각의 커밋을 개별적으로 밀어 넣었고 그것은 즉시 진행되었습니다.
또 다른 추가적인 것은, 제가 이 오류를 만났기 때문에 구글이 저를 여기로 데려갔기 때문입니다.
제 문제는 케이스의 불일치였습니다; 낙타 케이스 하나와 그렇지 않은 케이스 하나였습니다.분명히, GIT는 이유를 말하지 않고 당신이 이것을 하는 것을 막습니다.따라서 대문자로만 원격과 다른 지점이 있다면 동일하게 변경해 보십시오.
참조: Git: 병합 후 '마스터를 분기로 확인할 수 없습니다'
위의 답변 중 어떤 것도 저에게 효과가 없었습니다. 하지만 여기에 그 결과가 있습니다.
.git/의 에서.- 데스크톱과 새 : 원격레데같은새위치복:
git clone https://github.com/foo/bar.git - 이사를
.git/ - 변경 내용 다시 커밋 및 푸시
Windows용 Git를 사용하고 있는데(Windows 시스템에서 이 작업을 수행하는 경우) 여기에 나와 있는 다른 수정 사항이 제대로 작동하지 않는 경우 https://github.com/git-for-windows/git/releases, 으로 이동하여 버전 2.4.5 이후 버전을 받아 보십시오.날 위해 바로 고쳐줬어요.
기존 디렉토리 내에서 리포지토리를 복제한 경우 문제를 해결하려면 다른 디렉토리에 있는 리포지토리를 복제하고 변경 내용을 이 새 디렉토리에 복제한 다음 푸시를 실행하면 됩니다.
제 경우 Intellij Idea를 진행할 때 이 오류가 발생했습니다.
이것이 제가 실수를 추적하고 수정한 방법입니다.
- 터미널 내에서 디버그 로깅을 활성화합니다. 이는 결코 나쁜 생각이 아닙니다. :)
set GIT_CURL_VERBOSE=1 set GIT_TRACE=1
- Intellij를 경유하지 않고 터미널을 통해 푸시합니다.
git push
-> fatal: The current branch feature/my-new-feature has no upstream branch.
To push the current branch and set the remote as upstream
솔루션은 업스트림을 설정하는 것이었는데, 이전에는 잘못되었을 것입니다.
git push --set-upstream origin feature/my-new-feature
재포장을 통해 이 문제를 해결했습니다.
git repack --max-pack-size=100M -a -d
GitHub Desktop에서 Repository > Open in 명령 프롬프트로 이동합니다. 다음 명령을 실행합니다.
set GIT_TRACE=1
set GIT_CURL_VERBOSE=1
git push origin <branch>
최근에 저는 같은 문제에 직면했습니다.원격 저장소를 복제할 때 다음과 같은 오류가 발생했습니다.
이 예기치 않게 끊어진| 7KiB/s 파일: 원격끝예않게중 MiB | 7.00 KiB/s
: 초기 EOF
(인덱스 팩 실패)
구글에서 오류를 검색했을 때 여기로 리디렉션되었습니다.그리고 저는 대부분의 답을 따랐지만 제 문제를 해결하지 못했습니다.
유일한 해결책은 '네트워크 어댑터(WiFi) 드라이버 소프트웨어'를 다시 설치하는 것이었습니다.따라서 제가 강조하고 싶은 것은 위의 오류가 PC의 WiFi 드라이버 소프트웨어의 문제에서도 발생할 수 있다는 것입니다.언급된 답변이 작동하지 않는 경우 WiFi 드라이버를 다시 설치해 볼 수 있습니다.그것은 문제를 해결할 것입니다.
다음과 같이 WiFi 드라이버를 쉽게 다시 설치할 수 있습니다.
및 열기
'네트워크 재설정'을 선택합니다.
그런 다음 '지금 재설정'을 선택합니다.
PC를 재부팅한 후 GIT 작업을 성공적으로 시도합니다(푸시/풀/클론).
OSX 플랫폼을 업데이트한 후 이 문제가 발생할 수 있습니다.
.ssh-폴더로 한 후 .ssh-folder를 합니다.ssh-add -K ~/.ssh/id_rsa
PLESK Nginx와 GIT Pleskit에서 이 오류를 수신하고 있었고 (누가 무엇을 알고 있는지) 큰 repo를 푸시하는 동안 HTTP 코드 413으로 이 오류를 주었고 서버가 Plesk이고 nginx가 apache2와 함께 실행되고 있어서 로그를 조사하고 nginx 로그에서 오류를 발견했습니다.
이 링크를 따라 Plesk가 더 큰 파일 업로드로 구성을 재구성할 수 있습니다.
나는 git을 위해 php 부분을 건너뛰었습니다.
그 후 Git Push는 아무런 오류 없이 작동했습니다.
우리에게 문제는 gitfs에 의해 관리되어야 하는 파일이 엄청나게 많다는 것이었습니다.
문제를 해결하기 위해 다음을 수행했습니다.
# Soft reset so you can author a new commit
git reset --soft HEAD~1
# Install git lfs
git lfs install
# Track large files of a specified file type YMMV
git lfs track "*.uasset" "*.umap"
# Re-add everything
git add .
# Author a new commit
git commit -m "git lfs ftw"
# Push
git push
저는 우연히 같은 오류를 당했습니다.
저는 "http.postBuffer" 트릭을 했습니다.그것은 해결되었지만, 제가 밀고 싶을 때, 저는 다시 오류에 부딪혔습니다.
내 문제를 해결한 것:
다른 가상 시스템이 있는 다른 폴더로 복제했습니다(Linux).
옷 갈아입었어요.
처음에 푸시할 수 없었던 원래 가상 머신으로 푸시했습니다. (Windows)
저도 같은 문제가 있어요.Git 웹 페이지에서 SSH 클론 URL의 다음 구조를 확인했습니다.
git@github.com:user/project.git
다음과 같이 ":"를 "/"로 변경하기만 하면 문제를 해결할 수 있었습니다.
git@github.com/user/project.git
이것이 도움이 될 수도 있습니다.
천 가지 중 하나가 될 수 있을 것 같습니다.
저는 처음에 소스 트리를 통해 마스터 및 개발(마스터 변경 사항 없음)을 푸시하고 있었습니다.이것을 개발로 변경하는 것만 효과가 있었습니다.
저는 큰 레포를 업로드하는 중에 비슷한 오류에 직면해 있습니다.원격 끝이 예기치 않게 끊어졌습니다." 추가 세부 정보가 없습니다.
많은 연구 끝에, 제가 한 일은 다음과 같습니다.
- HTTPS 대신 SSH를 사용해도 문제가 해결되지 않았습니다.
- http.postBuffer를 매우 큰 값까지 점진적으로 증가시키지만 여전히 운이 없습니다.
- 저는 레포에 있는 큰 파일 때문일 수도 있다는 것을 알고(이것은 강제로 새로 마이그레이션된 레포이기 때문에) LFS를 사용하여 레포를 다시 생성하고 largeFile을 설정했습니다.임계값을 40m로 설정하여 리포 크기를 3.5G에서 500M으로 크게 줄입니다.저는 이것이 문제를 해결할 것이라고 생각했지만, 놀랍게도 여전히 같은 오류에 직면했습니다.
마지막으로, 추가 오류 메시지를 보지 못했기 때문에 이전 Git 클라이언트를 사용하고 있는 것 같습니다.git 클라이언트를 최신(2.20.1)으로 업그레이드했는데 voila, 오류가 사라졌습니다!
답변을 추가하는 것은 거의 무의미해 보이지만, 저는 오랫동안 이것과 싸우고 있었고, 마침내 제가 산발적으로 중단을 겪고 있는 것이 Visual Studio Online이라는 것을 알게 되었습니다.이러한 사실은 VS가 계속해서 크레딧을 요청하고 VSO 웹 사이트에서 500점을 제시하면서 명백해졌습니다.
Counting objects: 138816, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (38049/38049), done.
error: unable to rewind rpc post data - try increasing http.postBuffer
error: RPC failed; curl 56 SSL read: error:00000000:lib(0):func(0):reason(0), errno 10054
The remote end hung up unexpectedly/138816), 33.30 MiB | 3.00 KiB/s
Writing objects: 100% (138816/138816), 50.21 MiB | 3.00 KiB/s, done.
Total 138816 (delta 100197), reused 134574 (delta 96515)
fatal: The remote end hung up unexpectedly
Everything up-to-date
나중에 HTTP 게시 버퍼를 2MB로 다시 설정했습니다. 실제로는 더 작은 게시물에서 더 잘 작동한다고 생각하기 때문입니다.
언급URL : https://stackoverflow.com/questions/15240815/git-fatal-the-remote-end-hung-up-unexpectedly
'source' 카테고리의 다른 글
| hstack/vstack vs append vs concontate vs column_stack을 언제 사용해야 합니까? (0) | 2023.07.23 |
|---|---|
| PHP & localStorage; (0) | 2023.07.23 |
| 이것은 무엇을 의미합니까?"Parse error: 구문 오류, 예기치 않은 T_PAAMAYIM_NEKUDOTAYIM" (0) | 2023.07.23 |
| 자체 수정 코드를 사용하여 x86에서 오래된 명령 페칭을 관찰 (0) | 2023.07.23 |
| 풀에서 잘못된 데이터베이스 연결을 제거하는 방법 (0) | 2023.07.23 |