Моєму проекту шість місяців, а git дуже повільний. Ми відстежуємо близько 30 файлів розміром від 5 МБ до 50 МБ. Це двійкові файли, і ми зберігаємо їх у git. Я вважаю, що ці файли роблять git повільним.

Чи є спосіб убити всі файли розміром> 5 Мб із сховища. Я знаю, що втрачу всі ці файли, і це нормально зі мною.

В ідеалі я хотів би отримати команду, яка б перераховувала всі великі файли (> 5 МБ). Я бачу список, а потім кажу, що добре, видаліть ці файли та зробіть git швидшим.

Слід зазначити, що git працює повільно не тільки на моїй машині, але розгортання програми в проміжному середовищі зараз займає близько 3 годин.

Отже, виправлення повинно мати вплив на сервер, а не лише на користувачів сховища.

Ви збираєте сміття?

git gc

Це робить значну різницю в швидкості навіть для невеликих репо.

Пояснення

Git насправді добре володіє величезними історіями невеликих текстових файлів, оскільки може ефективно зберігати їх та їх зміни. У той же час git дуже погано справляється з двійковими файлами, і він буде наївно зберігати окремі копії файлу ( принаймні за замовчуванням ). Сховище стає величезним, а потім стає повільним, як ви вже спостерігали.

Це поширена проблема серед DVCS, що посилюється тим, що ви завантажуєте кожну версію кожного файлу ("ціле сховище") кожного разу, коли клонуєте. Хлопці з Kiln працюють над плагіном для обробки цих великих файлів більше як Subversion, який завантажує лише історичні версії на вимогу.

Рішення

Ця команда перелічить усі файли в поточному каталозі розміром> = 5 МБ.

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

Якщо ви хочете видалити файли з усієї історії сховища, ви можете скористатися цією ідеєю git filter-branchдля проходження історії та позбавлення від усіх слідів великих файлів. Після цього всі нові клони сховища стануть більш стрункими. Якщо ви хочете надати сховище без клонування, ви знайдете вказівки на сторінці довідок (див. "Контрольний список для зменшення сховища").

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

Слово попередження : це зробить ваше сховище несумісним з іншими клонами, оскільки дерева та індекси мають різні файли; ти більше не зможеш штовхати або тягнути від них.

Ось цензурована редакція, яка має бути менш негативною та запальною:

Git має добре відому слабкість, коли мова йде про файли, які не є рядковими текстовими файлами. В даний час рішення не існує, і жодні плани, оголошені основною командою git щодо вирішення цього питання. Існують обхідні шляхи, якщо ваш проект невеликий, скажімо, 100 МБ або близько того. Існують гілки проекту git для вирішення цієї проблеми масштабованості, але на даний момент ці гілки не є зрілими. Деякі інші системи контролю перегляду не мають цієї конкретної проблеми. Ви повинні розглядати це питання як лише один із багатьох факторів, коли приймаєте рішення, чи вибрати git як свою систему контролю версій.

У двійкових файлах і способі обробки ними git немає нічого конкретного. Коли ви додаєте файл до сховища git, додається заголовок, а файл стискається zlib і перейменовується після хешу SHA1. Це абсолютно однаково незалежно від типу файлу. У стисненні zlib немає нічого, що робить проблемою двійкові файли.

Але в деякі моменти (натискання, gc) Git починає розглядати можливість дельта-стиснення вмісту. Якщо git знаходить схожі файли (ім'я файлу тощо), він поміщає їх в оперативну пам'ять і починає стискати разом. Якщо у вас є 100 файлів, і кожен з них має 50 Мб, він намагатиметься одночасно помістити в пам’ять 5 Гб. До цього вам доведеться додати ще трохи, щоб все запрацювало. Ваш комп’ютер може не мати такої кількості оперативної пам’яті, і він починає мінятися місцями. Процес вимагає часу.

Ви можете обмежити глибину дельта-стиснення, щоб процес не використовував стільки пам'яті, але результат був менш ефективним. (core.bigFileThreshold, атрибут delta, pack.window, pack.depth, pack.windowMemory тощо)

Тому є багато думок, які ви можете зробити, щоб git працював дуже добре з великими файлами.

Одним із способів пришвидшити ситуацію є використання --depth 1прапора. Докладнішу інформацію див. На сторінці користувача. Я не великий git-гуру, але я вважаю, що це говорить робити еквівалент a p4 getабо an svn get, тобто це дає вам лише найновіші файли, замість "дати мені всі ревізії всіх файлів за весь час", що є що git cloneробить.

ви сказали git, що ці файли двійкові?

наприклад, доданий *.ext binaryдо вашого сховища.gitattributes

Ви також можете розглядати BFG Repo Cleaner як більш швидкий і простий спосіб очищення великих файлів.

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

Я запускаю Git з 2008 року як на Windows, так і на GNU / linux, і більшість файлів, які я відстежую, є двійковими. Деякі мої репозиторії складають кілька Гб і містять Jpeg та інші засоби масової інформації. У мене багато комп’ютерів як вдома, так і на роботі під управлінням Git.

У мене ніколи не було симптомів, які описані в оригінальному дописі. Але буквально пару тижнів тому я встановив MsysGit на старий ноутбук Win-XP, і майже все, що я зробив, зупинило git. Навіть тест із лише двома-трьома невеликими текстовими файлами був смішно повільним. Ми говоримо про 10 хвилин, щоб додати файл менше 1к ... здається, що git-процеси залишились живими назавжди. Все інше працювало, як очікувалося, на цьому комп’ютері.
Я перейшов із останньої версії до версії 1.6, і проблем не стало ... У
мене є інші ноутбуки тієї ж марки, також із встановленою Win-XP тим самим ІТ-відділом, формують однаковий образ, де Git чудово працює незалежно від версії. .. Отже, з цим конкретним комп’ютером має бути щось дивне.

Я також провів кілька тестів із двійковими файлами та стисненням. Якщо у вас є зображення BMP, і ви внесли в нього невеликі зміни та вчинили їх, git gc дуже добре стиснеться. Отже, мій висновок полягає в тому, що стиснення не залежить від того, є файли двійковими чи ні.

Просто налаштуйте файли на ігнорування. Дивіться посилання нижче:

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

Це тому, що git не є масштабованим.

Це серйозне обмеження в git, яке заглушується пропагандою git. Шукайте в списках розсилки git, і ви знайдете сотні користувачів, які задаються питанням, чому лише мізерні 100 МБ зображень (скажімо, для веб-сайту чи програми) ставлять git на коліна. Проблема полягає в тому, що майже весь git покладається на оптимізацію, яку вони називають "упаковкою". На жаль, упаковка неефективна для всіх текстових файлів, окрім найменших (тобто вихідний код). Гірше того, він зростає все менше та менш ефективним із збільшенням історії.

Це справді незручний недолік git, який рекламується як "швидкий" (незважаючи на відсутність доказів), і розробники git це добре знають. Чому вони не виправили? Ви знайдете відповіді у списку розсилки git від розробників git, які не розпізнають проблему, оскільки документи Photoshop (* .psd) є власним форматом. Так, це справді так погано.

Ось результат:

Використовуйте git для крихітних проектів лише з вихідним кодом, для яких вам не хочеться створювати окреме репо. Або для невеликих проектів лише з вихідним кодом, де ви хочете скористатися перевагами децентралізованої розробки git's copy-the-whole-repo. Або коли ви просто хочете вивчити новий інструмент. Все це вагомі причини використовувати git, і завжди цікаво вивчати нові інструменти.

Не використовуйте git, якщо у вас велика база кодів, двійкові файли, величезна історія тощо. Просто одне з наших репозиторіїв - це ТБ. Git не впорається. VSS, CVS та SVN чудово справляються з цим. (Однак SVN роздувається.)

Крім того, дайте часу git дозріти. Це ще незріле, але воно має великий імпульс. З часом, я думаю, що практичний характер Лінуса подолає пуристів OSS, і git з часом стане придатним для використання в більшій галузі.