내 프로젝트는 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을 실행하는 컴퓨터가 많이 있습니다.

원래 게시물에 설명 된 증상이 없었습니다. 하지만 불과 몇 주 전에 저는 오래된 Win-XP 랩탑에 MsysGit을 설치했고 제가했던 거의 모든 작업이 git을 중단 시켰습니다. 2 ~ 3 개의 작은 텍스트 파일로 테스트하는 것조차 엄청나게 느 렸습니다. 1k 미만의 파일을 추가하는 데 10 분 정도 소요됩니다. git 프로세스가 영원히 살아있는 것처럼 보입니다. 다른 모든 것은이 컴퓨터에서 예상대로 작동했습니다.
최신 버전에서 1.6으로 다운 그레이드했는데 문제가 사라졌습니다.
동일한 브랜드의 다른 랩톱도 있고 동일한 IT 부서에서 Win-XP를 설치하여 동일한 이미지를 형성합니다. 버전에 관계없이 Git이 잘 작동합니다. .. 그래서 그 특정 컴퓨터에 뭔가 이상한 것이있을 것입니다.

바이너리 파일과 압축으로 몇 가지 테스트를했습니다. BMP 사진이 있고 약간 변경하고 커밋하면 git gc가 매우 잘 압축됩니다. 그래서 내 결론은 압축이 파일이 바이너리인지 아닌지에 달려 있지 않다는 것입니다.

무시하도록 파일을 설정하십시오. 아래 링크를 참조하십시오.

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

git은 확장 가능하지 않기 때문 입니다.

이것은 git 옹호에 의해 익사되는 git의 심각한 한계입니다. git 메일 링리스트를 검색하면 100MB의 이미지 (예 : 웹 사이트 또는 응용 프로그램 용)가 왜 git을 무릎 꿇게하는지 궁금해하는 수백 명의 사용자를 찾을 수 있습니다. 문제는 거의 모든 git이 "패킹"이라고하는 최적화에 의존한다는 것입니다. 안타깝게도 압축은 가장 작은 텍스트 파일 (예 : 소스 코드)을 제외하고 모두 비효율적입니다. 더 나쁜 것은 역사가 증가함에 따라 점점 덜 효율적으로 성장한다는 것입니다.

이것은 (증거가 부족함에도 불구하고) "빠르다"고 선전되는 git의 부끄러운 결함이며 git 개발자들은이를 잘 알고 있습니다. 왜 고치지 않았나요? Photoshop 문서 (* .psd)가 독점 형식이기 때문에 문제를 인식하지 못하는 git 개발자의 git 메일 링 목록에서 답변을 찾을 수 있습니다. 예, 정말 그렇게 나쁩니다.

결과는 다음과 같습니다.

별도의 저장소를 설정하고 싶지 않은 작은 소스 코드 전용 프로젝트에 git을 사용하십시오. 또는 git의 분산 형 개발의 전체 저장소 모델을 활용하려는 소규모 소스 코드 전용 프로젝트의 경우. 또는 단순히 새로운 도구를 배우고 싶을 때. 이 모든 것이 git을 사용하는 좋은 이유이며 새로운 도구를 배우는 것은 항상 재미 있습니다.

큰 코드베이스, 바이너리, 방대한 히스토리 등이 있다면 git을 사용하지 마십시오. 우리 저장소 중 하나는 TB입니다. 힘내는 그것을 처리 할 수 ​​없습니다. VSS, CVS 및 SVN은 잘 처리합니다. (SVN은 부풀어 오른다.)

또한 git에게 성숙 할 시간을주세요. 아직 미숙하지만 추진력이 많습니다. 시간이 지나면 Linus의 실제적인 성격이 OSS 순수 주의자들을 극복 할 것이며 git은 결국 더 큰 분야에서 사용될 수있을 것이라고 생각합니다.