현재 나는
- 빈 GitHub 저장소
- SSH 서버 저장소 (기본)
- 지역 레포
SSH 서버 저장소는 최신 저장소 (생산 사이트)이므로 Git 복제본을 로컬에서 로컬로 수행했습니다. 그런 다음 git pushGitHub에 시도했습니다 .
모든 것이 괜찮 았지만 filename.gz에 대해 GitHub에 비해 너무 큽니다. 이 파일이 필요하지 않아 Git 캐시에서 제거하기 위해 여러 개의 Git 명령을 실행 한 다음 SSH 서버로 다시 푸시했습니다.
로컬에서 큰 파일을 볼 수는 없지만 git diff아무것도 반환하지 않고 git push가 “Everything is up-to-date”를 반환 하더라도 여전히 SSH 서버에 있습니다. GitHub 여전히 오류가 발생합니다
원격 : 오류 : 파일 fpss.tar.gz는 135.17MB입니다. 이것은 GitHub의 파일 크기 제한 인 100MB를 초과합니다.
GitHub 도움말에 나열된 “문제 해결”아래의 단계를 수행 했으므로 충분하지 않습니까?
파일이 로컬이 아니거나 git status / diff / push에 나열되어있을 때 어떻게 에테르에 남아 있습니까?
답변
당신이 사용할 수있는
git filter-branch --index-filter 'git rm -r --cached --ignore-unmatch <file/dir>' HEAD
해당 파일 기록의 모든 내용이 삭제됩니다. 문제는 파일이 기록에 있다는 것입니다.
이 명령은 커밋의 해시를 변경하여 특히 공유 리포지토리에서 실제 문제가 될 수 있습니다. 결과를 이해하지 않고 수행해서는 안됩니다.
답변
스 쿼싱 이보다 유용하다는 것을 알았 습니다 filter-branch. 나는 다음을 수행했다.
- 큰 파일을 로컬에서 삭제하십시오.
- 로컬 삭제를 커밋합니다.
- 소프트 커밋 다시 X 커밋 수 (3의 경우) :
git reset.
--soft HEAD~3 - 그런 다음 모든 변경 사항을 다시 커밋하십시오 (AKA 스쿼시)
git commit -m
"New message for the combined commit" - 스쿼시 커밋을 푸시하십시오.
특수한 경우 (사용자 @lituo) : 위의 방법으로 문제가 해결되지 않으면이 사례가있을 수 있습니다. 커밋 1에 큰 파일이 포함되었고 커밋 1의 푸시는 큰 파일 오류로 인해 실패했습니다. 커밋 2가 큰 파일을 제거git rm --cached [file_name]했지만 커밋 2의 푸시는 여전히 실패했습니다. 당신은 위의 대신 사용하여 동일한 단계를 수행 할 수 있습니다HEAD~3, 사용HEAD~2.
답변
도움을 요청하기 전에 이미 리포지토리에 엉망이 되었으면 도움이 될만한 것이 있습니다. 첫 번째 유형 :
git status
이 후, 당신은 라인을 따라 뭔가를 볼 수 있습니다
On branch master
Your branch is ahead of 'origin/master' by 2 commits.
(use "git push" to publish your local commits)
nothing to commit, working tree clean
중요한 부분은 “2 commits”입니다! 여기에서 다음을 입력하십시오.
git reset HEAD~<HOWEVER MANY COMMITS YOU WERE BEHIND>
따라서 위의 예에서 다음을 입력하십시오.
git reset HEAD~2
입력 한 후에 “git status”는 다음과 같아야합니다.
On branch master
Your branch is up to date with 'origin/master'.
nothing to commit, working tree clean
여기에서 큰 파일을 삭제하고 (아직 수행하지 않은 경우) 작업 손실없이 모든 것을 다시 커밋 할 수 있어야합니다.
나는 이것이 멋진 답변이 아니라는 것을 알고 있지만 도움이되기를 바랍니다.
답변
파일이 경우 가장 최근의 커밋을 당신과 함께 추가 , 당신은 원격 저장소에 밀어하지 않은 , 당신은 파일을 삭제하고이에서 촬영, 커밋 수정할 수 있습니다 여기에 :
git rm --cached giant_file
# Stage "giant_file" for removal with "git rm"
# Leave it on disk with "--cached". if you want to remove it from disk
# then ignore the "--cached" parameter
git commit --amend -CHEAD
# Commit the current tree without the giant file using "git commit"
# Amend the previous commit with your change "--amend"
# (simply making a new commit won't work, as you need
# to remove the file from the unpushed history as well)
# Use the log/authorship/timestamp of the last commit (the one we are
# amending) with "-CHEAD", equivalent to --reuse-message=HEAD
git push
# Push our rewritten, smaller commit with "git push"
답변
비슷한 문제가 있었고 위 의 단계를 사용 하여 파일을 제거했습니다. 완벽하게 작동했습니다.
그런 다음 제거해야 할 두 번째 파일에 오류가 발생했습니다.
remote: error: File <path/filename> is 109.99 MB; this exceeds GitHub's file size limit of 100.00 MB
같은 단계를 시도했지만 오류가 발생했습니다. "A previous backup already exists in <path/filename>"
이 웹 사이트 에서 조사한 결과 다음 명령을 사용했습니다.git filter-branch --force --index-filter "git rm --cached --ignore-unmatch <path/filename>" --prune-empty --tag-name-filter cat -- --all
훌륭하게 작동했으며 큰 파일이 제거되었습니다.
믿을 수 없을 정도로, 여전히 다른 오류로 인해 푸시에 실패했습니다. error: RPC failed; curl 56 OpenSSL SSL_read: SSL_ERROR_SYSCALL, errno 104 fatal: The remote end hung up unexpectedly
이것은 .git 설정 파일을 직접 수정하여 수정했습니다. postBuffer = 999999999
그 후 푸시는 통과했다!
답변
큰 파일을 삭제 한 후에도 GitHub가 내 저장소를 거부하는 이유는 무엇입니까?
Git은 프로젝트의 전체 히스토리를 저장하므로 프로젝트에서 파일을 ‘삭제’하더라도 Git 저장소에는 여전히 히스토리에 파일 사본이 있으며 다른 저장소 (예 : GitHub) 다음 Git 에는 원격 저장소에 로컬 저장소와 동일한 기록이 있어야합니다 (즉, 기록에있는 동일한 큰 파일).
GitHub가 레포를 수락하도록하려면 어떻게해야합니까?
프로젝트의 Git 히스토리를 로컬로 정리하고 모든 히스토리에서 원하지 않는 큰 파일을 제거한 다음 앞으로 ‘세척 된’히스토리 만 사용하십시오. 영향을받는 커밋의 Git 커밋 ID가 변경됩니다.
Git 저장소에서 큰 파일을 어떻게 정리합니까?
Git 히스토리에서 원하지 않는 큰 파일을 정리하는 가장 좋은 도구는 BFG Repo-Cleanergit-filter-branch 입니다. Git 히스토리에서 원하지 않는 파일을 제거하기 위해 특별히 설계된 것보다 간단하고 빠른 대안 입니다.
사용 지침을주의 깊게 따르십시오. 핵심 부분은 다음과 같습니다.
$ java -jar bfg.jar --strip-blobs-bigger-than 100M my-repo.git
100MB 이상의 파일 ( 최근 커밋에 없는 파일 )은 Git 리포지토리 기록에서 제거됩니다. 그런 다음 git gc죽은 데이터를 정리 하는 데 사용할 수 있습니다 .
$ git gc --prune=now --aggressive
BFG는 일반적으로 적어도이다 10-50x 빠르게 실행하는 것보다 git-filter-branch, 사용이 일반적으로 더 쉽게.
전체 공개 : 저는 BFG Repo-Cleaner의 저자입니다.
답변
나는 같은 문제를 겪었고 아무런 대답도 나에게 도움이되지 않았다. 다음 단계로 해결했습니다.
1. 큰 파일을 포함하는 커밋을 찾습니다
git log --all -- 'large_file`
맨 아래 커밋은 결과 목록에서 가장 오래된 커밋입니다.
2. 가장 오래된 것 중 하나를 찾으십시오.
git log
당신이 가지고 있다고 가정 해보십시오 :
commit 3f7dd04a6e6dbdf1fff92df1f6344a06119d5d32
3. 힘내 rebase
git rebase -i 3f7dd04a6e6dbdf1fff92df1f6344a06119d5d32
팁 :
- 목록 항목
drop커밋에 큰 파일이 포함되도록 선택 합니다.- 리베이스 수정 중에 충돌이 발생
git rebase --continue하여 완료 할 때까지 계속 사용할 수 있습니다. - 리베이스 중에 문제가 발생하면이
git rebase --abort를 취소하십시오.
