Git LFS 건너 뛰기 파일이지만 git이 repo 파일로 건너 뛰기 시작합니다

Question

git lfs를 사용하여 일반적으로 업로드 한 내 Github 저장소에 큰 파일이 있습니다. 새로운 커밋의 경우, 파일을 변경해야했지만, 이제는 git lfs가 파일을 건너 뛰고 일반 git이 업로드를 시도합니다. 이것은 물론 Github의 최대 파일 크기를 초과하므로 실패합니다.

trace git-lfs: run_command: 'git' version trace git-lfs: run_command: 'git' config -l trace git-lfs: tq: running as batched queue, batch size of 100 trace git-lfs: run_command: ssh -- git@github.com git-lfs-authenticate myRepo.git upload trace git-lfs: HTTP: POST https://lfs.github.com/myRepo/locks/verify trace git-lfs: HTTP: 200 trace git-lfs: HTTP: {"ours":[],"theirs":[],"next_cursor":""}

trace git-lfs: pre-push: refs/heads/master d7b0e4138403023433894f756d63bdadfabac125 refs/heads/master 683a30586bc68758230da6686fa902d4621b358a trace git-lfs: run_command: git rev-list --objects d7b0e4138403023433894f756d63bdadfabac125 --not --remotes=origin -- trace git-lfs: run_command: git cat-file --batch trace git-lfs: tq: sending batch of size 1 trace git-lfs: ssh cache: git@github.com git-lfs-authenticate myRepo.git upload trace git-lfs: api: batch 1 files trace git-lfs: HTTP: POST https://lfs.github.com/myRepo/objects/batch trace git-lfs: HTTP: 200 trace git-lfs: HTTP: {"objects":[{"oid":"1e24fed72634c9217ce7856d11ee204d38eb154fc90572a8ef047007f2211a6c","size":246116656}]} trace git-lfs: tq: starting transfer adapter "basic" Git LFS: (0 of 0 files, 1 skipped) 0 B/0 B, 234.72 MB skipped
17:22:37.083227 run-command.c:343 trace: run_command: 'pack-objects' '--all-progress-implied' '--revs' '--stdout' '--thin' '--delta-base-offset' '--progress' 17:22:37.084316 exec_cmd.c:128
trace: exec: 'git' 'pack-objects' '--all-progress-implied' '--revs' '--stdout' '--thin' '--delta-base-offset' '--progress' 17:22:37.088704 git.c:348 trace: built-in: git 'pack-objects' '--all-progress-implied' '--revs' '--stdout' '--thin' '--delta-base-offset' '--progress' Counting objects: 109, done. Delta compression using up to 4 threads.

Compressing objects: 100% (106/106), done. Writing objects: 100% (109/109), 73.55 MiB | 1.81 MiB/s, done. Total 109 (delta 74), reused 0 (delta 0) remote: Resolving deltas: 100% (74/74), completed with 53 local objects. remote: error: GH001: Large files detected. You may want to try Git Large File Storage - https://git-lfs.github.com . remote: error: Trace: e87aee9bcda79c0a788ae345112c9d37 remote: error: See http://git.io/iEPt8g for more information. remote: error: File src/ios/sdk/myLib.framework/Framework is 234.72 MB; this exceeds GitHub's file size limit of 100.00 MB To git@github.com:myRepo.git ! [remote rejected] master -> master (pre-receive hook declined) error: failed to push some refs to 'git@github.com:myRepo.git'

Answer 1

그것은 인덱스에 파일의 새 버전을 추가 할 때 clean 필터가 적용되지 않은 LFS 같은 소리 : 내가

GIT_TRACE=1 git push

를 실행하면 이 출력입니다. 파일 이름이 변경되지 않으면 해당 경로가 LFS에 연결되는 .gitattributes 파일이 없음을 의미합니다. (이전에 파일을 처음 추가했을 때 수동으로 필터를 수동으로 실행했거나 커밋되지 않았거나 커밋되지 않았거나 더 이상 제거되지 않았거나 수정 된 것입니다. 파일과 일치합니다 ... 등)

그리고 파일 이름이 변경된 경우 .gitattributes 파일의 경로와 일치하지 않는 것으로 변경되었을 가능성이 있습니다. 따라서 .gitattributes를 업데이트하여 새 파일 이름과 일치시켜야합니다.

일단 파일이 LFS 추적으로 준비되면 인덱스 및 데이터베이스에서 볼 수있는 git이 LFS 포인터 파일입니다. 따라서 속성 파일이 제거 되더라도 즉시 큰 파일이 repo 데이터베이스에 업로드되지는 않습니다. 그러나 파일을 다시 추가하고 수정 한 후에 속성을 설정하지 않으면 포인터 파일 대신 전체 파일이 준비됩니다.

위의 추적에서 LFS가 건너 뛴 이유는 파일의 이전 버전이 서버에 이미 있기 때문입니다. 이것은 정상입니다.

하지만 밀어 넣으려고하는 커밋은 좋지 않습니다. 그것은 전체 파일을 취소 불가능하게 그 안에 포함합니다. 전체 파일이있는 각 커밋을 수정 (또는 rebase 또는 다른 방법으로 다시 작성)해야합니다. 다행스럽게도 커밋을 공유하지 못하게하면 다른 사람이 "업스트림 리베이스"상황에 빠지게하지 않고 안전하게 다시 작성할 수 있어야합니다.

그래서 요약 :

당신이 LFS가 큰 파일을 일치하는 경로 속성을 할당하는 .gitattributes 파일이 있는지 확인합니다. 이 .gitattributes 파일을 색인에 추가해야합니다.

큰 파일의 새 버전을 제거했다가 다시 색인화하십시오.

git rm --cached path/to/big/file 
git add path/to/big/file 

.gitattributes가 올바르게 설정되어있는 경우, LFS 청정 필터이 시간을 통해 갈 것이다 add; 포인터 파일이 색인에 추가되고 새 LFS 오브젝트가 작성됩니다.

git commit --amend 

는 그게 LFS를 사용하여 새 것으로 내장 큰 BLOB을 갖는 저지하기.

이제 시도해보십시오. 그래도 실패하면, 수정해야 할 커밋이있을 수 있고, 커밋이 더 복잡해 질 수 있습니다.