Git로 대용량 이진 파일 관리

Git로 대용량 이진 파일 관리

제 소스 코드(웹 애플리케이션)가 종속된 대용량 이진 파일을 어떻게 처리해야 할지 의견을 찾고 있습니다.현재 몇 가지 대안에 대해 논의하고 있습니다.

1. 이진 파일을 직접 복사합니다.
   • 찬성: 확실하지 않습니다.
   • 반대: 새 사이트를 설정하거나 이전 사이트를 마이그레이션할 때 오류가 발생할 가능성이 높기 때문에 이에 강력히 반대합니다.또 다른 장애물을 만듭니다.
2. Git로 모든 것을 관리합니다.
   • 찬성: 중요한 파일을 '잊어버리고' 복사할 가능성을 제거합니다.
   • 반대: 저장소를 부풀리고 코드 기반을 관리하기 위한 유연성을 줄이며 체크아웃, 클론 등은 상당한 시간이 소요됩니다.
3. 저장소를 분리합니다.
   • 찬성: 소스 코드를 체크아웃/클론하는 것은 언제나 빠르며 이미지는 자신의 저장소에 적절하게 보관됩니다.
   • 반대: 프로젝트에 하나뿐인 Git 저장소가 있는 단순성을 제거합니다.그것은 확실히 제가 생각하지 못했던 다른 것들을 소개합니다.

이에 대한 귀하의 경험/생각은 어떻습니까?

또한: 여러 Git 저장소를 사용하여 한 프로젝트에서 관리한 경험이 있는 사람이 있습니까?

파일은 해당 파일이 포함된 PDF를 생성하는 프로그램의 이미지입니다.파일은 몇 년 동안처럼 자주 변경되지는 않지만 프로그램과 매우 관련이 있습니다.파일이 없으면 프로그램이 작동하지 않습니다.

저는 최근에 Git-Annex를 발견했는데, 그것은 제가 대단하다고 생각합니다.대용량 파일을 효율적으로 관리하기 위해 설계되었습니다.사진/음악(등) 컬렉션에 사용합니다.Git-Annex의 개발은 매우 활발합니다.파일의 내용은 Git 저장소에서 제거할 수 있으며 트리 계층만 Git에 의해(심링크를 통해) 추적됩니다.그러나 파일의 내용을 가져오려면 다음과 같이 풀/푸시 후 두 번째 단계가 필요합니다.

$ git annex add mybigfile
$ git commit -m'add mybigfile'
$ git push myremote
$ git annex copy --to myremote mybigfile ## This command copies the actual content to myremote
$ git annex drop mybigfile ## Remove content from local repo
...
$ git annex get mybigfile ## Retrieve the content
## or to specify the remote from which to get:
$ git annex copy --from myremote mybigfile

많은 명령을 사용할 수 있으며 웹 사이트에 훌륭한 설명서가 있습니다.데비안에서 패키지를 이용할 수 있습니다.

파일 없이 프로그램이 작동하지 않으면 별도의 레포로 분할하는 것은 좋지 않은 생각인 것 같습니다.별도의 레포로 분할되는 대규모 테스트 제품군이 있지만, 이는 진정한 "보조" 파일입니다.

그러나 별도의 저장소에서 파일을 관리한 후 를 사용하여 프로젝트에 파일을 올바르게 가져올 수도 있습니다.따라서 모든 소스의 전체 이력은 여전히 보유하고 있지만, 제가 이해하기로는 이미지 서브모듈에 대한 관련 수정본은 하나뿐입니다.그git-submodule기능을 사용하면 올바른 버전의 코드를 올바른 버전의 이미지와 일치하도록 유지할 수 있습니다.

Git Book의 서브모듈에 대한 좋은 소개입니다.

2015년 4월 이후 또 다른 솔루션은 GitHub의 Git Large File Storage(LFS)입니다.

git-lfs(git-lfs.github.com 참조)를 사용하고 지원하는 서버 lfs-test-server:
메타데이터는 gitrepo에만 저장할 수 있고 큰 파일은 다른 곳에 저장할 수 있습니다.

Git 저장소에 큰 바이너리를 스마트하게 저장하기 위한 Git 확장인 Git bup를 살펴보세요.

서브모듈로 사용하고 싶지만 저장소 처리가 어려워질 염려가 없습니다.샘플 사용 사례 중 하나는 Git에 VM 이미지를 저장하는 것입니다.

압축률이 향상된 것은 아니지만 저장소에 대용량 이진 파일이 없습니다.

마일리지는 변동될 수 있습니다.

지방을 사용할 수도 있습니다.저는 그것이 오직 재고 파이썬과에만 의존한다는 것이 좋습니다.또한 다음과 같은 자체 설명 명령을 사용하여 일반 Git 워크플로우를 지원합니다.

git fat init
git fat push
git fat pull

.git fat관리할 수 있습니다.

인 " 을사이추가다니합진을여"를 합니다.git add그것이 차례로 유발합니다.git fatGit 속성 규칙을 기반으로 합니다.

마지막으로, 파일이 간에 할 수 항목을 할 수 있다는 .rsync 그렇습니다.

업데이트: Git-SVN 브리지를 사용하는 경우 Git-fat를 사용하지 마십시오.그러면 하위 버전 저장소에서 이진 파일이 제거됩니다.하지만 순수한 Git 저장소를 사용하고 있다면, 그것은 아름답게 작동합니다.

서브모듈(Pat Notz) 또는 두 개의 서로 다른 저장소를 사용할 것입니다.바이너리 파일을 너무 자주 수정하면 기록을 정리하는 대용량 저장소의 영향을 최소화할 수 있습니다.

몇 달 전에도 비슷한 문제가 있었습니다. 최대 21GB의 MP3 파일, 분류되지 않은 파일(나쁜 이름, 나쁜 ID3, 내가 그 MP3 파일을 좋아하는지 아닌지 모르겠다...), 그리고 세 대의 컴퓨터에서 복제되었습니다.

외부 하드 디스크 드라이브를 메인 Git 저장소와 함께 사용하여 각 컴퓨터에 복제했습니다.그런 다음, 저는 그것들을 습관적인 방식으로 분류하기 시작했습니다(밀기, 당기기, 병합하기...).여러 번 삭제 및 이름 변경).

마지막에는 .git 디렉토리에 최대 6GB의 MP3 파일과 최대 83GB의 파일만 있었습니다.저는 용한사를 요.git-write-tree그리고.git-commit-tree조상들을 약속하지 않고 새로운 약속을 만들고, 그 약속을 가리키는 새로운 지부를 시작했습니다.해당 분기의 "git log"에는 커밋이 하나만 표시되었습니다.

그런 다음 이전 분기를 삭제하고 새 분기만 유지한 다음 ref-log를 삭제하고 "git prune"을 실행했습니다. 그 후 .git 폴더의 가중치는 ~6GB입니다.

동일한 방법으로 때때로 거대한 저장소를 "제거"할 수 있습니다. 즉, "git clone"이 더 빨라집니다.

제가 제안하고 싶은 솔루션은 고립된 분기와 태그 메커니즘의 약간의 남용에 기반을 둔 것입니다. 이를 *Orphan Tags Binary Storage(OTABS)라고 합니다.

TL;DR 12-01-2017 Github의 LFS 또는 다른 제3자를 사용할 수 있다면 반드시 사용해야 합니다.만약 당신이 할 수 없다면, 계속 읽으세요.주의: 이 솔루션은 해킹이므로 그렇게 취급해야 합니다.

OTABS의 바람직한 특성

• Git-Annex와 같은 타사 소프트웨어나 Git-hub의 LFS와 같은 타사 인프라 없이도 작업을 수행할 수 있는 순수한 Git 및 Git 전용 솔루션입니다.
• 이진 파일을 효율적으로 저장합니다. 즉, 저장소의 기록을 부풀리지 않습니다.
• git pull그리고.git fetch를 포함하여, 을 포함하여git fetch --all대역폭 효율적입니다. 즉, 기본적으로 모든 대형 바이너리가 원격에서 풀링되지는 않습니다.
• Windows에서 작동합니다.
• 모든 것을 하나의 git 저장소에 저장합니다.
• 오래된 바이너리를 삭제할 수 있습니다(버프와 달리).

OTABS의 바람직하지 않은 특성

• 그것은 만듭니다.git clone잠재적으로 비효율적입니다(사용 용도에 따라 반드시 그렇지는 않습니다).에게 이솔을배경동사조록할언도수있다습니도야해용하게료루를 사용하도록 해야 할 수도 .git clone -b master --single-branch <url>에 git clone이는 기본적으로 Git clone이 참조되지 않는 커밋과 같이 대역폭을 일반적으로 낭비하지 않으려는 항목을 포함하여 전체 저장소를 문자 그대로 복제하기 때문입니다.SO 4811434에서 발췌.
• 그것은 만듭니다.git fetch <remote> --tags대역폭이 비효율적이지만 반드시 스토리지가 비효율적인 것은 아닙니다.당신은 항상 동료들에게 그것을 사용하지 말라고 충고할 수 있습니다.
• 으로 으사합니다야해용로적을 해야 할 git gc더 이상 원하지 않는 파일에서 리포지토리를 정리하는 방법.
• 그것은 bump나 git-big 파일만큼 효율적이지 않습니다.그러나 이는 각각 여러분이 하려는 일에 더 적합하고 더 기성품에 더 적합합니다.수십만 개의 작은 파일이나 기가바이트 범위의 파일에서 문제가 발생할 수 있지만 해결 방법을 계속 읽어 보십시오.

이진 파일 추가

모든 변경사항을 커밋하기 전에 작업 트리가 최신 상태이고 인덱스에 커밋되지 않은 변경사항이 포함되어 있지 않은지 확인합니다.재해가 발생할 경우 모든 로컬 지점을 원격(기트 허브 등)으로 푸시하는 것이 좋습니다.

1. 새 독립 분기를 만듭니다. git checkout --orphan binaryStuff 다른 이 상위 항목이 커밋이 .이렇게 하면 다른 분기와 완전히 연결되지 않은 분기가 생성되고, 이 분기에서 처음 수행할 커밋에는 상위 항목이 없으므로 루트 커밋이 됩니다.
2. 다을사여인정을 사용하여 합니다.git rm --cached * .gitignore.
3. 을 하고 흡 을 하 트 작 리 삭 제 업 체 전 여 하 고rm -fr * .gitignore.내부의.git디렉터리는 그대로 유지됩니다. 왜냐하면*와일드카드가 일치하지 않습니다.
4. VeryBigBinary.exe 또는 Very로 복사무거운 디렉토리/.
5. 추가하고 커밋합니다.
6. . , 의 모든 은 다음 이 이제그까다다니를 호출할 때 할 입니다. 만약 당신이 그것을 브랜치로 원격에 밀어넣는다면, 당신의 모든 개발자들은 다음 번에 그들이 그것을 실행할 때 다운로드 할 것입니다.git fetch그들의 연결을 방해하는 것.분기 대신 태그를 눌러 이 문제를 방지할 수 있습니다.이는 동료가 입력하는 습관이 있는 경우에도 여전히 동료의 대역폭 및 파일 시스템 스토리지에 영향을 미칠 수 있습니다.git fetch <remote> --tags하지만 계속해서 문제 해결을 위해 읽습니다. 어가서.git tag 1.0.0bin
7. 태그 ㅠㅠㅠㅠㅠㅠㅠgit push <remote> 1.0.0bin.
8. 를 밀지 할 수 .git branch -D binaryStuff컬렉션으로 . 는 해당 커밋을 입니다. 커밋이 가비지 수집을 가리키고 있기 때문입니다.1.0.0bin목숨을 유지하기에 충분합니다.

이진 파일 체크아웃

1. VeryBigBinary.exe를 현재 작업 트리에 체크아웃하려면 어떻게 해야 합니까?현재 작업 중인 브랜치가 예를 들어 마스터일 경우에는 간단히 수행할 수 있습니다.git checkout 1.0.0bin -- VeryBigBinary.exe.
2. 태그가 실패합니다.1.0.0bin다운로드되었습니다. 이 경우 당신은 해야 할 것입니다.git fetch <remote> 1.0.0bin사전에
3. 다니있을 할 수 .VeryBigBinary.exe로..gitignore당신 팀의 아무도 실수로 바이너리로 프로젝트의 주요 역사를 오염시키지 않을 것입니다.

이진 파일을 완전히 삭제하는 중

로컬 리포지토리, 원격 리포지토리 및 동료의 리포지토리에서 VeryBigBinary.exe를 완전히 제거하기로 결정한 경우 다음 작업을 수행할 수 있습니다.

1. 원서분 에서 고아 git push <remote> :refs/tags/1.0.0bin
2. 로컬에서 참조되지 않은 태그는 ).git tag -l | xargs git tag -d && git fetch --tagsSO 1841341에서 약간 수정한 내용입니다.
3. Gitc 트릭을 사용하여 참조되지 않은 커밋을 로컬에서 삭제합니다. git -c gc.reflogExpire=0 -c gc.reflogExpireUnreachable=0 -c gc.rerereresolved=0 -c gc.rerereunresolved=0 -c gc.pruneExpire=now gc "$@"또한 다른 참조되지 않은 커밋도 모두 삭제됩니다.SO 1904860에서 발췌
4. 가능하면 리모컨에서 Gitgc 트릭을 반복합니다.저장소를 자체 호스팅하는 경우 github 또는 일부 기업 환경과 같은 일부 git 공급자에서는 가능하지 않을 수 있습니다.원격에 대한 SSH 액세스 권한을 제공하지 않는 공급자와 호스팅하는 경우에는 그냥 내버려 두십시오.공급자의 인프라가 참조되지 않은 커밋을 적절한 시간에 정리할 수 있습니다.기업 환경에 있는 경우 IT 부서에 일주일에 한 번 정도 원격을 수집하는 cron 작업 쓰레기를 실행하도록 조언할 수 있습니다.사용자가 항상 동료에게 조언하는 한 대역폭 및 스토리지 측면에서 사용자 팀에 영향을 미치지 않습니다.git clone -b master --single-branch <url>에 git clone.
5. 오래된 고아 태그를 제거하려는 모든 동료는 2-3단계만 적용하면 됩니다.
6. 그런 다음 이진 파일 추가의 1-8 단계를 반복하여 새 분리 태그를 만들 수 있습니다.2.0.0bin이 타이핑하는 ㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠgit fetch <remote> --tags 지을 수 .1.0.0bin이렇게 하면 다음에 모든 태그를 가져올 때 오래된 태그를 가져오게 됩니다.1.0.0bin참조되지 않고 이후 가비지 수집에 대해 표시됩니다(3단계 사용). 원에서태덮때어쓸을 사용해야 합니다.-f와 같이: 과같이다음:git push -f <remote> <tagname>

뒷말

• OTABS는 마스터나 다른 소스 코드/개발 분기를 건드리지 않습니다.커밋 해시, 모든 내역 및 이러한 분기의 작은 크기는 영향을 받지 않습니다.이미 이진 파일로 소스 코드 기록을 부풀린 경우 별도의 작업으로 정리해야 합니다.이 스크립트는 유용할 수 있습니다.

• Git-bash로 Windows에서 작동하는 것으로 확인되었습니다.

• 이진 파일을 보다 효율적으로 저장하기 위해 일련의 표준 시도를 적용하는 것이 좋습니다.의 빈번한 실행git gc(추가 인수 없이) 이진 델타를 사용하여 파일의 기본 스토리지를 최적화할 수 있습니다.그러나 파일이 커밋에서 커밋까지 유사하게 유지되지 않을 경우 이진 델타를 모두 해제할 수 있습니다.또한 .zip, .jpg 또는 .crypt와 같이 이미 압축되었거나 암호화된 파일을 압축하는 것은 의미가 없기 때문에 git을 사용하면 기본 저장소의 압축을 해제할 수 있습니다.안타깝게도 이 설정은 소스 코드에도 영향을 줍니다.

• OTABS의 일부를 스크립팅하여 더 빠르게 사용할 수 있습니다.특히 이진 파일을 완전히 삭제하는 단계에서 다음으로 스크립팅하는 단계 2-3updategithook은 gitfetch에 강제적이지만 위험한 의미를 부여할 수 있습니다("오래된 모든 것을 삭제하고 삭제").

• 중앙 저장소 블롯 비용으로 원격의 모든 이진 변경 내용에 대한 전체 기록을 유지하려면 이진 파일을 완전히 삭제하는 4단계를 건너뛸 수 있습니다.로컬 리포지토리는 시간이 지남에 따라 기울어진 상태로 유지됩니다.

• 자바 세계에서는 이 솔루션을 다음과 결합하는 것이 가능합니다.maven --offline전체 버전 컨트롤에 저장된 재생 가능한 오프라인 빌드를 만듭니다(마븐으로 하는 것이 그라들로 하는 것보다 더 쉽습니다).골랑 세계에서는 이 솔루션을 기반으로 GOPATH를 관리하는 것이 가능합니다.go get하지 않고 할 수 .python world에서는 PyPi 서버에 의존하지 않습니다.

• 아티팩트와 이진 변경되는 버전의 태그에 .monday_bin,tuesday_bin, ...,friday_bin 릴리스에 대한 .1.7.8bin 2.0.0bin 타를 시킬 수 . 회전할 수 있습니다.weekday_bin이전 이진 파일을 매일 삭제합니다.이렇게 하면 소스 코드의 전체 기록은 유지하고 이진 종속성의 관련 기록만 유지할 수 있습니다.또한 모든 이력이 포함된 전체 소스 코드를 가져오지 않고도 지정된 태그의 이진 파일을 가져오는 것이 매우 쉽습니다.git init && git remote add <name> <url> && git fetch <name> <tag>당신을 위해 그것을 해야 합니다.

제 생각에, 당신이 종종 그 큰 파일들을 수정할 가능성이 있거나 혹은 당신이 많은 것을 만들 의도가 있다면,git clone또는git checkout그런 다음 다른 Git 저장소(또는 해당 파일에 액세스하는 다른 방법)를 사용하는 것을 진지하게 고려해야 합니다.

그러나 NAT처럼 작업하고 이진 파일이 자주 수정되지 않는 경우에는 첫 번째 클론/체크아웃 시간이 길지만, 그 후에는 사용자가 처음 복제된 저장소를 계속 사용하는 것을 고려하여 원하는 만큼 빨라야 합니다.

SVN은 Git보다 이진 델타를 더 효율적으로 처리하는 것 같습니다.

문서화를 위한 버전 관리 시스템(JPEG 파일, PDF 파일, .odt 파일)을 결정해야 했습니다.저는 방금 JPEG 파일을 추가하고 90도 회전을 4번 시도했습니다(바이너리 델타의 효과를 확인하기 위해).Git의 저장소는 400% 증가했습니다.SVN의 저장소는 11% 증가하는 데 그쳤습니다.

따라서 SVN은 이진 파일에서 훨씬 더 효율적입니다.

그래서 제가 선택한 것은 소스 코드의 경우 Git이고 문서와 같은 이진 파일의 경우 SVN입니다.

git clone --filter 2+ Git 2.19 + 은얕클서론에.

Git 및 GitHub가 개발하고 충분히 사용자 친화적으로 만든다면 이 새로운 옵션은 결국 바이너리 파일 문제의 최종 해결책이 될 수 있습니다(예를 들어 서브모듈에 대해서는 아직 달성하지 못한 것이 분명합니다).

실제로 서버에 대해 원하는 파일 및 디렉터리만 가져올 수 있으며 원격 프로토콜 확장과 함께 도입되었습니다.

이를 통해 먼저 얕은 클론을 만든 다음 각 빌드 유형에 대해 빌드 시스템에서 가져올 블롭을 자동화할 수 있습니다.

심지어 이미 있습니다.--filter=blob:limit<size>가져올 최대 블롭 크기를 제한할 수 있습니다.

Git 저장소의 하위 디렉터리만 복제하려면 어떻게 해야 합니까? 기능이 어떻게 작동하는지에 대한 최소한의 자세한 예를 제공했습니다.

제 소스 코드(웹 애플리케이션)가 종속된 대용량 이진 파일을 어떻게 처리해야 할지 의견을 찾고 있습니다.이에 대한 귀하의 경험/생각은 어떻습니까?

개인적으로 웹 애플리케이션 바이너리 데이터가 3GB를 초과하면 일부 클라우드 호스트에서 Git와의 동기화가 실패했습니다.당시 BFT Repo Cleaner를 고려했지만, 해킹처럼 느껴졌습니다.그 이후로 저는 파일 관리, 버전 관리 및 백업을 위해 Amazon S3와 같은 특수 제작 도구를 활용하는 대신 Gitpurview 외부에 파일을 보관하기 시작했습니다.

여러 Git 저장소를 사용하여 한 프로젝트에서 관리한 경험이 있는 사람이 있습니까?

네. 휴고 테마는 주로 이런 식으로 관리됩니다.약간 어색하지만, 일을 잘 해냅니다.

---

제 제안은 그 일에 적합한 도구를 선택하는 것입니다.회사를 위한 것이고 GitHub에서 코드라인을 관리하고 있다면 돈을 지불하고 Git-LFS를 사용합니다.그렇지 않으면 블록체인을 사용하여 분산된 암호화된 파일 스토리지와 같은 보다 창의적인 옵션을 탐색할 수 있습니다.

고려해야 할 추가 옵션으로는 Minio 및 s3cmd가 있습니다.

Git LFS가 정답입니다.

# Init LFS
git lfs install
git lfs track "large_file_pattern"

# Then follow regular git workflow
git add large_file
git commit -m "Init a very large file"
git push origin HEAD

장면 뒤에서 gitfs는 큰 파일에 대한 참조를 생성하고 gitrepo에 직접 저장하지 않습니다.

자세한 내용은 https://git-lfs.github.com/ 에서 확인하시기 바랍니다.

캠리스토어를 보세요.Git 기반은 아니지만, 당신이 해야 할 일에 더 적합하다고 생각합니다.

언급URL : https://stackoverflow.com/questions/540535/managing-large-binary-files-with-git