Git LFS 문제 해결

Git LFS를 사용할 때 다음과 같은 문제가 발생할 수 있습니다.

n개의 파일을 포인터로 추적해야 했지만 그렇게 되지 않았음

이 오류는 파일이 LFS에 의해 추적되도록 예상되지만 저장소가 그들을 LFS로 추적하지 않고 있음을 나타냅니다. 이 문제의 잠재적인 이유는 다음 중 하나일 수 있습니다: 웹 인터페이스를 통해 업로드된 파일이 LFS로 추적되지 않음

문제를 해결하려면, 영향을 받는 파일(또는 파일)을 마이그레이션하고 저장소로 다시 푸시하십시오:

  1. 파일을 LFS로 마이그레이션: 

    git lfs migrate import --yes --no-rewrite "<your-file>"

  2. 저장소로 다시 푸시: 

    git push

  3. 선택 사항. .git 폴더를 정리: 

    git reflog expire --expire-unreachable=now --all
git gc --prune=now

error: 저장소 또는 객체를 찾을 수 없음

이 오류는 몇 가지 이유로 발생할 수 있습니다.

  • 특정 LFS 객체에 액세스할 수 있는 권한이 없는 경우

프로젝트에 푸시할 권한이 있는지 또는 프로젝트에서 가져올 수 있는지 확인하십시오.

  • 프로젝트가 LFS 객체에 액세스할 수 없음

푸시하려고 하는 LFS 객체에 더 이상 프로젝트가 액세스할 수 없습니다. 아마도 객체가 서버에서 제거되었을 것입니다.

  • 로컬 Git 저장소가 사용 중단된 LFS API를 사용하고 있음

<url>에 대한 유효하지 않은 상태 : 501

Git LFS는 실패 사항을 로그 파일에 기록합니다. 이 로그 파일을 보려면 프로젝트 디렉토리 내에서 다음을 실행하십시오. 

git lfs logs last

상태 error 501가 표시되는 경우:

  • 프로젝트 설정에서 Git LFS가 활성화되지 않았습니다. 프로젝트 설정을 확인하고 Git LFS를 활성화하십시오.

  • GitLab 서버에서 Git LFS 지원이 활성화되지 않았습니다. GitLab 관리자에게 문의하여 GitLab 서버에서 왜 Git LFS가 활성화되지 않았는지 확인하십시오. 지침은 LFS 관리 문서에서 확인할 수 있습니다. LFS 지원을 활성화하는 방법에 대한 지침을 확인하십시오.

  • GitLab 서버에서 Git LFS 클라이언트 버전이 지원되지 않습니다. Git LFS 버전을 git lfs version로 확인하십시오. 프로젝트의 Git 구성을 확인하여 사용 중단된 API의 흔적을 확인하십시오. 구성에 batch = false가 설정되어 있는 경우, 해당 줄을 제거하고 Git LFS 클라이언트를 업데이트하십시오. 1.0.1 버전 이상만 지원됩니다.

getsockopt: 연결 거부됨

프로젝트에 LFS 객체를 푸시하고 이와 같은 오류를 받는 경우, LFS 클라이언트는 HTTPS를 통해 GitLab에 도달하려고 시도합니다. 그러나 GitLab 인스턴스가 HTTP로 제공되고 있습니다: 

Post <URL>/info/lfs/objects/batch: dial tcp IP: getsockopt: connection refused

이 동작은 Git LFS가 Git 구성에 lfsurl이 설정되지 않았을 때 기본적으로 HTTPS 연결을 사용하기 때문에 발생합니다.

이러한 문제를 방지하려면 프로젝트 Git 구성에서 LFS URL을 설정하십시오: 

git config --add lfs.url "http://gitlab.example.com/group/my-sample-project.git/info/lfs"

객체를 푸시할 때 항상 자격 증명이 필요함

참고: 8.12 GitLab에서 SSH에 LFS 지원이 추가되었습니다. Git LFS 통신은 아직 HTTP를 통해 이루어지지만 이제 SSH 클라이언트가 올바른 자격 증명을 Git LFS 클라이언트에게 전달합니다. 사용자는 조치를 취할 필요가 없습니다.

Git LFS는 모든 객체에 대한 각 푸시에서 HTTP 기본 인증을 통해 사용자를 인증하므로 사용자 HTTPS 자격 증명이 필요합니다.

기본적으로 Git은 사용하는 각 저장소에 대한 자격 증명을 기억하는 기능을 지원합니다. 자세한 내용은 공식 Git 문서를 참조하십시오.

예를 들어, 해당 객체를 푸시할 것으로 예상되는 시간 동안 암호를 기억하도록 Git에 지시할 수 있습니다: 

git config --global credential.helper 'cache --timeout=3600'

이는 1시간 동안 자격 증명을 기억하며, 이후 Git 작업에서 재인증이 필요합니다.

OS X를 사용하는 경우 osxkeychain을 사용하여 자격 증명을 저장하고 암호화할 수 있습니다. Windows를 사용하는 경우 wincred 또는 Microsoft의 Windows용 Git 자격 증명 관리자를 사용할 수 있습니다.

사용자 자격 증명을 저장하는 여러 가지 방법에 대한 자세한 내용은 Git 자격 증명 저장소 문서에서 확인할 수 있습니다.

푸시 시 LFS 객체가 누락됨

GitLab은 푸시 시 LFS 포인터를 감지하여 파일을 확인합니다. LFS 포인터가 감지되면 GitLab은 해당 파일이 이미 GitLab의 LFS에 있는지 확인하려고 시도합니다.

로컬로 LFS가 설치되어 있는지 확인하고 git lfs push --all로 수동 푸시를 고려하십시오.

GitLab 외부에 LFS 파일을 저장하고 있는 경우 projects API를 사용하여 프로젝트에서 LFS를 비활성화할 수 있습니다.

외부로 LFS 객체 호스팅하기

git config -f .lfsconfig lfs.url https://example.com/<project>.git/info/lfs와 같이 사용자 정의 LFS URL을 설정하여 외부에서 LFS 객체를 호스팅할 수 있습니다.

이렇게 하는 이유는 LFS 데이터를 저장하는 Nexus Repository와 같은 장비를 사용하는 경우일 수 있습니다. 외부 LFS 스토어를 사용하는 경우 GitLab은 LFS 객체를 확인할 수 없습니다. 따라서 GitLab LFS 지원이 활성화된 상태에서 푸시에 실패할 수 있습니다.

푸시 실패를 방지하려면 프로젝트 설정에서 LFS 지원을 비활성화할 수 있습니다. 이렇게 하면 GitLab LFS 부가 기능(확인하는 LFS 객체, LFS용 UI 통합)도 비활성화됩니다.

LFS 객체를 푸시할 때 I/O 타임아웃 발생

다음과 같은 오류가 발생할 수 있습니다. 

LFS: Put "http://your-instance.com/root/project.git/gitlab-lfs/objects/cc29e205d04a4062d0fb131700e8bfc8e54c44d0176a8dca22f40b24ef26d325/15": read tcp your-instance-ip:54544->your-instance-ip:443: i/o timeout
error: failed to push some refs to 'ssh://your-instance.com:2222/root/project.git'

네트워크 상태가 불안정할 때 Git LFS 클라이언트는 파일을 업로드하려고 시도할 때 시간 초과될 수 있습니다.

이 문제를 해결하려면 클라이언트 활동 타임아웃 값을 더 높게 설정하면 됩니다.

예를 들어, 타임아웃을 60초로 설정하려면: 

git config lfs.activitytimeout 60