Картинки виявились великими і тупо не влізли в сервер, бо там є обмеження на розмір. Проте це наслідок, а причина в тому, як git узагалі влаштований.
Він заточений під текст, хоча працює це не зовсім так, як здається. Git і для тексту кладе файл цілком, а вже потім, коли пакує історію, стискає версії й рахує дельти між ними. Текст стискається чудово: помінялось одне слово, і в пак лягає різниця на пару байт.
Бінарник не стискається. Він або вже стиснутий, або просто шумний, тому дельта між двома версіями виходить розміром із сам файл. Десять ітерацій одного макета це десять майже повних макетів в історії, і кожен, хто робить clone, тягне їх усі.
Для цього й придумали LFS, Large File Storage. Файл їде в окреме сховище, а в репі лишається текстовий вказівник на версію, тож при клоні стягується одна актуальна замість усього кладовища. Увімкнув, перепушив, пролізло, а MR я потім прибив, бо скріншоти вже подивився.
Тобто бінарники в git це нормально. Ненормально класти їх туди як є.
А вони у вас мабуть вже є, просто непомітні і ніхто на них не дивиться: фікстури й дампи для тестів, шрифти, іконки, PDF у документації, макети і тд.
Вмикається воно не тумблером у себе локально, а файлом .gitattributes у репі, бо це домовленість усієї команди. А сам
git-lfs це окремий пакет, з git він не ставиться. Я цього разу нічого не ставив тільки тому, що поставив його колись давно і забув, а хто не поставив, побачить замість макета текстовий файл із хешем і піде питати, хто зламав йому репозиторій 🙂І все, можна комітити бінарники. Прикольно, що деякі галузі досі сидять на інших системах контролю версій: у gamedev це Perforce, бо він уміє в бінарники з коробки і ще й лочить файл, щоб двоє художників не правили одну модель. Схоже, LFS їх так і не переконав.
І вмикати варто до, а не після. Після це вже переписування історії й можливо неприємна розмова з усіма, хто цю репу клонував.
З вас лайк та історія, який файл у вашій репі виявився найважчим і як він туди взагалі потрапив.