git은 큰 바이너리 파일을 추적 할 때 매우 느립니다.

git은 큰 바이너리 파일을 추적 할 때 매우 느립니다.

---

내 프로젝트는 6 개월이 지났고 git은 매우 느립니다. 우리는 크기가 5MB에서 50MB 인 약 30 개의 파일을 추적합니다. 바이너리 파일이며 git에 보관합니다. 나는 그 파일이 git을 느리게 만들고 있다고 생각합니다.

저장소에서 크기가 5MB를 초과하는 모든 파일을 죽이는 방법이 있습니까? 이 모든 파일을 잃어 버릴 것이라는 것을 알고 있으며 괜찮습니다.

이상적으로는 모든 큰 파일 (> 5MB)을 나열하는 명령을 원합니다. 목록을 볼 수 있으며 괜찮다고 말하고 파일을 삭제하고 git을 더 빠르게 만듭니다.

git은 내 컴퓨터에서 느릴뿐만 아니라 스테이징 환경에 앱을 배포하는 데 약 3 시간이 걸립니다.

따라서 수정 사항은 저장소 사용자뿐만 아니라 서버에 영향을주는 것이어야합니다.

---

쓰레기 수거합니까?

git gc

이것은 작은 저장소의 경우에도 속도면에서 상당한 차이를 만듭니다.

---

설명

Git은 작은 텍스트 파일과 그 변경 사항을 효율적으로 저장할 수 있기 때문에 방대한 양의 텍스트 파일 기록을 잘 처리합니다. 동시에 git은 바이너리 파일에서 매우 나쁘고 파일의 별도 사본을 순진하게 저장합니다 ( 기본적으로 최소한 ). 보시다시피 저장소가 커지고 느려집니다.

이것은 복제 할 때마다 모든 파일 ( "전체 저장소")의 모든 버전을 다운로드한다는 사실로 인해 악화되는 DVCS의 일반적인 문제입니다. Kiln 의 사람들은 이러한 대용량 파일을 주문형으로 만 기록 버전을 다운로드하는 Subversion과 비슷하게 처리하는 플러그인을 개발하고 있습니다.

해결책

이 명령은 현재 디렉토리 크기가 5MB 이상인 모든 파일을 나열합니다.

find . -size +5000000c 2>/dev/null -exec ls -l {} \;

저장소의 전체 기록에서 파일을 제거하려는 경우이 아이디어를 사용 git filter-branch하여 기록을 살펴보고 대용량 파일의 모든 흔적을 제거 할 수 있습니다 . 이렇게하면 저장소의 모든 새 복제본이 더 간결 해집니다. 복제하지 않고 리포지토리를 정리하려면 man 페이지 에서 지침을 찾을 수 있습니다 ( "리포지토리 축소를위한 체크리스트"참조).

git filter-branch --index-filter \
    'find . -size +5000000c 2>/dev/null -exec git rm --cached --ignore-unmatch {} \;'

경고 : 트리와 인덱스에 체크인 된 파일이 다르기 때문에 저장소 가 다른 복제본과 호환되지 않게 됩니다. 더 이상 밀거나 당길 수 없습니다.

---

다음은 덜 부정적이고 선동적인 검열 개정판입니다.

Git은 줄 단위 텍스트 파일이 아닌 파일과 관련하여 잘 알려진 약점을 가지고 있습니다. 현재 해결책이 없으며 핵심 git 팀에서이 문제를 해결할 계획을 발표하지 않았습니다. 프로젝트가 100MB 정도의 작은 경우 해결 방법이 있습니다. 이 확장 성 문제를 해결하기위한 git 프로젝트의 분기가 있지만 이러한 분기는 현재 성숙되지 않았습니다. 일부 다른 개정 제어 시스템에는 이러한 특정 문제가 없습니다. 개정 제어 시스템으로 git을 선택할지 여부를 결정할 때이 문제를 여러 요소 중 하나로 간주해야합니다.

---

바이너리 파일과 git이 파일을 처리하는 방식에 대해서는 특별한 것이 없습니다. git 저장소에 파일을 추가하면 헤더가 추가되고 파일은 zlib로 압축되고 SHA1 해시 후에 이름이 변경됩니다. 이것은 파일 유형에 관계없이 정확히 동일합니다. zlib 압축에는 바이너리 파일에 문제가되는 것은 없습니다.

그러나 어떤 시점에서 (pushing, gc) Git은 콘텐츠를 델타 압축 할 가능성을 찾기 시작합니다. git이 비슷한 파일 (파일 이름 등)을 찾으면 RAM에 넣고 함께 압축하기 시작합니다. 100 개의 파일이 있고 각 파일이 50Mb라고 말하면 동시에 5GB를 메모리에 넣으려고합니다. 이것에 당신은 일을 작동시키기 위해 더 추가해야합니다. 컴퓨터에이 양의 RAM이 없을 수 있으며 스왑을 시작합니다. 이 과정은 시간이 걸립니다.

프로세스가 그다지 많은 메모리를 사용하지 않지만 결과적으로 압축 효율이 떨어지도록 델타 압축의 깊이를 제한 할 수 있습니다. (core.bigFileThreshold, 델타 속성, pack.window, pack.depth, pack.windowMemory 등)

따라서 git이 대용량 파일에서 매우 잘 작동하도록 할 수있는 방법이 많이 있습니다.

---

속도를 높이는 한 가지 방법은 --depth 1깃발 을 사용하는 것 입니다. 자세한 내용은 man 페이지를 참조하십시오. 나는 훌륭한 자식 전문가 아니라고하지만 이것은에 해당 할라고 믿는다 p4 get또는를 svn get당신에게 단지 대신은 "모든 타임 아웃을 통해 나에게 모든 파일의 버전을 모두 제공"의 최신 파일을 줄입니다, 무엇을 git clone합니다.

---

git에게 그 파일이 바이너리라고 말했습니까?

예를 들어 *.ext binary저장소에 추가.gitattributes

---

BFG Repo Cleaner를 대용량 파일을 더 빠르고 쉽게 정리하는 방법으로 고려할 수도 있습니다.

https://rtyley.github.io/bfg-repo-cleaner/

---

저는 2008 년부터 Windows와 GNU / linux에서 Git을 실행 해 왔으며 제가 추적하는 대부분의 파일은 바이너리 파일입니다. 내 저장소 중 일부는 몇 GB이고 Jpeg 및 기타 미디어를 포함합니다. 집과 직장에서 Git을 실행하는 컴퓨터가 많이 있습니다.

I have never had the symptoms that are described by the original post. But just a couple of weeks ago I installed MsysGit on an old Win-XP Laptop and almost whatever I did, it brought git to a halt. Even test with just two or three small text files was ridiculously slow. We are talking about 10 minutes to add a file less that 1k... it seems like the git processes stayed alive forever. Everything else worked as expected on this computer.
I downgraded from the latest version to 1.6 something and the problems were gone...
I have other Laptops of the same brand, also with Win-XP installed by the same IT department form the same image, where Git works fine regardless of version... So there must be something odd with that particular computer.

I have also done some tests with binary files and compression. If you have a BMP picture and you make small changes to it and commit them, git gc will compress very well. So my conclusion is that the compression is not depending on if the files are binary or not.

---

Just set the files up to be ignored. See the link below:

http://help.github.com/git-ignore/

---

That's because git isn't scalable.

This is a serious limitation in git that is drowned out by git advocacy. Search the git mailing lists and you'll find hundreds of users wondering why just a meager 100 MB of images (say, for a web site or application) brings git to its knees. The problem appears to be that nearly all of git relies on an optimization they refer to as "packing". Unfortunately, packing is inefficient for all but the smallest text files (i.e., source code). Worse, it grows less and less efficient as the history increases.

It's really an embarrassing flaw in git, which is touted as "fast" (despite lack of evidence), and the git developers are well aware of it. Why haven't they fixed it? You'll find responses on the git mailing list from git developers who won't recognize the problem because they Photoshop documents (*.psd) are proprietary format. Yes, it's really that bad.

Here's the upshot:

Use git for tiny, source-code only projects for which you don't feel like setting up a separate repo. Or for small source-code only projects where you want to take advantage of git's copy-the-entire-repo model of decentralized development. Or when you simply want to learn a new tool. All of these are good reasons to use git, and it's always fun to learn new tools.

Don't use git if you have a large code base, binaries, huge history, etc. Just one of our repos is a TB. Git can't handle it. VSS, CVS, and SVN handle it just fine. (SVN bloats up, though.)

Also, give git time to mature. It's still immature, yet it has a lot of momentum. In time, I think the practical nature of Linus will overcome the OSS purists, and git will eventually be usable in the larger field.

참고URL : https://stackoverflow.com/questions/3055506/git-is-very-very-slow-when-tracking-large-binary-files