Чи є спосіб зменшити розмір папки git?

Здається, мій проект з кожним виступом стає все більшим і більшим commit/push. Чи є спосіб очистити мою папку git?

Я не впевнений, чого ти хочеш. Перш за все, звичайно, щоразу, коли ви вводите / натискаєте каталог, він стає трохи більшим, оскільки він повинен зберігати кожен із цих додаткових комісій.

Однак, ймовірно, ви хочете, git gcщо "очистить непотрібні файли та оптимізує локальний сховище" ( сторінка з посібником ).

Інша, можливо, відповідна команда - git cleanце видалення файлів, що не відслідковуються, з вашого дерева ( сторінка вручну ).

Виконати:

git remote prune origin

Видаляє всі відстояні гілки відстеження, які вже видалено, originале все ще доступні локально remotes/origin.

git gc --auto

' G arbage C ollection' - виконує завдання з ведення господарства (стискає доопрацювання, видаляє сипучі / недоступні об'єкти). Спочатку --autoпрапор визначає, чи потрібна якась робота, і виходить, не виконуючи нічого, якщо ні.

Один із сценаріїв, коли ваше git repo буде ставати серйозно більшим із кожним фіксуванням, це той, коли ви створюєте двійкові файли, які ви регулярно створюєте. Їх зберігання не буде настільки ефективним, як текстовий файл .

Інший - це той, де у вас є величезна кількість файлів у межах одного репо (що є лімітом git ) замість кількох підрепортажів ( керованих як підмодулі ).

У цій статті про git space AlBlue згадує:

Зауважте, що Git (і Hg, і інші DVCS) страждають від проблеми, коли (великі) двійкові файли перевіряються, потім видаляються, оскільки вони все одно з’являться у сховищі та займають місце, навіть якщо вони не є поточними .

Якщо у вашому git repo зберігаються великі бінарні файли, ви можете врахувати:

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

Як я вже говорив в « Які межі файлів в Git (кількість і розмір)? », Тим більше в останній час (2015-го, через 5 років після цієї відповіді) Git LFS з GitHub є спосіб управління цими великими файлами (зберігаючи їх поза Сховище Git).

так Так, git gc це рішення, природно,

та локально - ви можете просто видалити локальне сховище та знову його клонувати,

але тут є щось важливіше ...

секунди, які ви чекаєте, коли величезні git & externals для обробки збираються на довгі хвилини, за які збираються години неефективного часу,

Створіть нове (цілком, а не лише гілка) сховище з нуля , включаючи єдину останню версію файлів, природно ви втратите всю історію,

але коли в кодовому світі не настав час сентиментальності, немає сенсу перетягувати коди протягом усіх 5 років на кожну фіксацію чи різницю, ви все одно можете зберігати старі git & externals де-небудь, якщо ви відчуваєте ностальгію:]

але в якийсь момент вам дійсно доведеться рухатись далі:]

ваша команда буде вам вдячна!

Запуск цієї команди надзвичайно небезпечно, але зменшить ваш сховище, видаливши всі файли відновлення / резервного копіювання git:

git reflog expire --expire=now --all && git gc --prune=now --aggressive

Це видалить усі файли, якими користується git, щоб відновити ваш сховище з якоїсь поганої команди, наприклад, якщо ви це зробили git reset --hard, зазвичай ви можете відновити втрачені файли. Але якщо ти зробиш git reset --hardперед git reflog expire...командою, то втратив усе. Тепер ваша єдина надія - скористатись інструментом, який аналізує вашу файлову систему та намагається відновити видалені файли, якщо вони не були відмінені.

git clean -d -f -i це найкращий спосіб зробити це.

Це допоможе очистити більш контрольований спосіб.

-i розшифровується як інтерактивний.

Не знаю, чи скоротить це, але після запуску git cleanя також часто роблю git repack -adце, що зменшує кількість файлів упаковки.