Робота з великими репозиторіями в Git

У Git можна ефективно відстежувати еволюцію бази коду та вести розробку разом із колегами. Але як бути, якщо ви хочете відстежувати величезний репозиторій?

У цій статті я пропоную кілька рішень щодо такої проблеми.

Дві категорії великих репозиторіїв

Репозиторії можуть сильно розростатися з однієї з двох основних причин:

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

А іноді буває і те, й інше.

Друга проблема іноді може посилюватись тим, що з репозиторію вчасно не видаляють застарілі двійкові артефакти. Рішення тут досить просте, хоч і стомлююче (див. далі).

Методи та обхідні шляхи будуть різними у кожному сценарії, але в деяких випадках вони можуть і доповнювати один одного. Я опишу кожен окремо.

Клонування репозиторіїв із дуже довгою історією

По-справжньому великі репозиторії – рідкість, але це не скасовує того, що клонувати їх дуже складно. А уникнути довгої історії вдається не завжди: часом репозиторій не можна скоротити через нормативні чи юридичні вимоги.

Просте рішення: поверхневе клонування git

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

Як це робиться? Просто використовуйте параметр depth. Наприклад:

git clone --depth [глибина] [віддалений-url]

Припустимо, що репозиторій містить історію проекту завдовжки 10 років чи більше.Наприклад, ми перенесли в Git базу коду Jira, що нагромадилася за 11 років.

Розмір повного клону Jira складає 677 МБ, а робочого каталогу, що містить більше 47 000 коммітів, - ще 320 МБ. часу зростає пропорційно до кількості двійкових файлів, нагромаджених у проекті.

Пов'язані матеріали

Переміщення повного репозиторію Git

Див. РІШЕННЯ

Вивчіть Git за допомогою Bitbucket Cloud

Порада: поверхневе клонування з тією ж користю можна застосовувати і в системах збирання, підключених до репозиторію Git.

Оскільки раніше деякі операції мали мізерну підтримку, поверхневе клонування в Git застосовувалося обмежено.

Ювелірна точність: git filter-branch

Для наведення порядку у великих репозиторіях з великою кількістю створеного помилково двійкового «сміття» і старих, непотрібних файлів відмінно підійде команда git filter-branchВона крок за кроком перевіряє всю історію проекту, фільтруючи, змінюючи або пропускаючи файли за заданим алгоритмом.

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

Синтаксис має такий вигляд:

git filter-branch --tree-filter 'rm -rf [/path/to/spurious/asset/folder]'

За всієї користі у команди git filter-branch є незначний недолік: фактично листується вся історія проекту, тому змінюються всі ідентифікатори комітів. Через це кожному розробнику доведеться вкотре клонувати оновлений репозиторій.

Якщо ви збираєтеся виконати очищення за допомогою git filter-branch, попередьте про це команду та призупиніть роботу на час виконання операції, а потім попросіть колег створити новий клон репозиторію.

Альтернатива git shallow-clone: ​​клонування лише однієї гілки

Починаючи з версії 1.7.10, в Git також можна клонувати окремі гілки, тим самим обмежуючи обсяг історії, що копіюється:

git clone [remote url] --branch [branch_name] --single-branch [folder]

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

Управління репозиторіями з величезними двійковими файлами

Інший тип високих репозиторіїв характеризується двійковими файлами великих розмірів. З ними зіштовхуються різні команди розробників ПЗ (і не тільки). Розробники ігор маніпулюють великими 3D-моделями, веб-розробники відстежують необроблені зображення, а команди САПР працюють із двійковими продуктами та відстежують їхній стан.

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

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

Але щоб вибрати успішний підхід, важливо врахувати характер двійкових файлів у проекті. Ось кілька підказок.

• Різнісне стиснення, найімовірніше, виявиться марним, якщо істотно змінюються самі двійкові файли, а чи не просто заголовки метаданих. Вкажіть такі файли -delta, щоб не виконувати різницеве ​​стиснення при перепакуванні, коли це недоцільно.
• У наведеному вище сценарії файли навряд чи підходять і для стиснення за допомогою zlib, тому є сенс відключити стиснення, вказавши core.compression 0 або core.loosecompression 0. Це глобальне налаштування, тому помістіть двійкові файли в окремий репозиторій, якщо стиснення потрібно зберегти для інших файлів, для яких вона більш актуальна.
• Важливо пам'ятати, що команда git gc пакує «повторювані» вільні об'єкти в один файл, однак такий пакет не заощадить багато місця без стиснення файлів усередині.
• Спробуйте змінити параметр core.bigFileThreshold. За промовчанням будь-які файли розміром більше 512 МБ не піддаються різницевому стиску (без внесення змін до .gitattributes). Можливо, коригування порогового значення дозволить заощадити ресурси.

Рішення для великих дерев папок: git sparse-checkout

Пом'якшити проблему двійкових файлів допомагає вибіркове перемикання sparse-checkout (доступно починаючи з Git 1.7.0). Цей метод дозволяє вказати папки, які потрібно заповнити, і не засмічувати робочий каталог. На жаль, використання sparse-checkout ніяк не вплине на загальний розмір локального репозиторію, зате полегшить роботу з «гіллястим» деревом папок.

Для цього можна використати, наприклад, такі команди.

• Клонуйте повний репозиторій один раз: git clone
• Активуйте функцію: git config core.sparsecheckout true
• Додайте потрібні папки явно, ігноруючи папки з файлами:
  • echo src/ › .git/info/sparse-checkout
  • git read-tree -m -u HEAD

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

  Рішення для керування оновленням великих файлів: підмодулі

  [ОНОВЛЕННЯ] …А ще можна забути все, що ви прочитали вище, і скористатися Git LFS

  Якщо ви регулярно працюєте з великими файлами, найкращим виходом може стати підтримка великих файлів (LFS) – рішення, розроблене Atlassian спільно з GitHub у 2015 році. (Так, все правильно: ми об'єдналися з GitHub, щоб реалізувати проект Git з відкритим вихідним кодом.)

  Розширення Git LFS дозволяє зберігати в репозиторії не самі великі файли, а лише (природно!) покажчики на них. Самі файли зберігаються на віддаленому сервері. Як неважко здогадатися, час клонування репозиторію завдяки цьому значно зменшується.

  Bitbucket, як і GitHub, теж підтримує Git LFS, тому технологія вам, швидше за все, вже доступна. Вона особливо корисна для команд, у яких працюють дизайнери, відеооператори, музиканти чи користувачі САПР.

  Висновок

  Не відмовляйтеся від чудових можливостей Git тільки через велику історію репозиторію або величезні файли. Обидві проблеми можна ефективно вирішити.

  Перейдіть за посиланнями в цьому тексті, щоб прочитати інші статті та дізнатися більше про підмодулі, залежність проектів та рішення Git LFS. А якщо хочете освіжити в пам'яті команди або робочий процес, вам є безліч навчальних посібників на нашому мікросайті, присвяченому Git. Вдалого програмування!

  Nicola is all-round hacker who loves exploring and teaching bleeding edge technologies. Він пише і розмовляє про Git, розробка workflows, код collaboration і більше останніх про Docker. Prior to його поточної ролі як Developer Instigator в Atlassian he led software teams, побудови пов'язаних applications for geo-spacial data, працювали на великих e-commerce deployments.Малі відомі факти про Nicola: я gesticulates lot while speaking (being Italian), живуть в Amsterdam і rides a Ducati.

  Saved searches

  Use saved searches to filter your results more quickly

  Ви написали з іншою tab або window. Reload to refresh your session. Ви надіслали в інший tab або window. Reload to refresh your session. Ви перераховані облікові записи на інший tab або window. Reload to refresh your session.

  GitHub Community

  Розмір репозиторію #51671

  Select Topic Area

  Body

  Який максимальний розмір репозиторію?

  Beta Was this translation helpful? Give feedback.

  1 You must be logged in to vote

  Replies: 2 comments

  >'s edit

  >'s edit

  You can check this link:

  Якщо ви знайдете це reply useful, please kindly 'Mark as answer' so that others know this issue is already addressed.

  Beta Was this translation helpful? Give feedback.

  1 You must be logged in to vote

  We recommend repositories remain small, ideally less than 1 GB, and less than 5 GB is strongly recommended

  Beta Was this translation helpful? Give feedback.

  1 You must be logged in to vote

  Codespaces Ваш розвиток навколишнього середовища, в cloud. Run VS Code and code на GitHub's cloud platform,

  Select a reply

  1 reacted with thumbs up emoji 👎 1 reacted with thumbs down emoji 😄 1 reacted with laugh emoji 🎉 1 reacted with hooray emoji 🚀 1 reacted with rocket emoji 👀 1 reacted with eyes emoji

  Footer

  You can't perform that action at this time.

  Git: робота з gitHUB

  Треба сказати, що у gitHUB чимало конкурентів: gitLab, BitBucket, SourceForge, Launchpad, Apache Allura та багато інших сервісів. Така велика кількість сервісів обґрунтована тим, що саме ядро ​​git-сервера, на якому працює gitHUB і його конкуренти - безкоштовне і ніхто не забороняє вам самому створити власний git-сервіс зі своїми унікальними фішками.

  Завантаження віддаленого репозиторію

  Репозиторії, розміщені на gitHUB, можуть бути публічними — відкритими для скачування всім бажаючим і приватними — доступними для скачування лише авторизованим користувачам, яким адміністратор репозиторію надав права. Для того, щоб завантажити репозиторій на локальну машину, потрібно визначити директорію, куди буде завантажено проект і виконати команду git clone [url] , де url - це посилання на віддалений репозиторій.

  Знайти посилання на репозиторій можна у вкладці Code:

  Просто скопіюйте шлях, скориставшись кнопкою швидкого копіювання у вигляді двох квадратів і вставте посилання в термінал:

  Завантажений репозиторій матиме не тільки файли проекту, але й директорію .git, де зберігатимуться всі git-об'єкти, а значить ви можете також переміщатися по гілках та комітах завантаженого репозиторію. Єдине, щоб побачити всі віддалені гілки репозиторію, необхідно застосувати команду git branch -r.

  При завантаженні віддаленого репозиторію git автоматично встановлює зв'язок між завантаженим репозиторієм і його віддаленою версією, тому оновлювати локальний репозиторій тепер можна командою git pull, перебуваючи в main гілці. Ви також можете завантажувати зміни, внесені в локальний репозиторій на віддалений сервер, якщо у вас є відповідні права.

  Давайте перейдемо тепер на gitHUB і попрацюємо з ним щільніше - створимо віддалений репозиторій, зв'яжемо його з локальним репозиторієм і завантажимо в нього зміни.

  Створення віддаленого репозиторію та завантаження в нього коду проекту

  Увійдіть на gitHUB і через іконку свого облікового запису перейдіть в розділ «репозиторії», там через кнопку «New» створіть новий репозиторій:

  На наступному кроці необхідно задати ім'я репозиторію, вказати його тип (публічний або приватний) та задати опис репозиторію:

  Після успішного створення репозиторію ви побачите вітальну сторінку з короткими, але дуже корисними інструкціями. Вони описано як синхронізувати віддалений і локальний репозиторії. Давайте це зробимо.

  Детальну інструкцію щодо створення репозиторію ми наводили в першій частині циклу статей, зараз наведемо її коротко:

  1. Створимо директорію для проекту командою mkdir;
  2. Ініціалізуємо репозиторій командою git init;
  3. Створимо файл readme.md і запишемо кілька рядків;
  4. Відправимо всі зміни до індексу командою git add.;
  5. Створимо перший коміт командою git commit-m «First commit»;
  6. Перейменуємо основну гілку в main - git branch -M main;

  Тепер нам потрібно зв'язати локальний та віддалений репозиторії командою git remote add origin https://[gitHUB_ACCESS_TOKEN]@gitHUB.com/[User name]/[repo name].git . Origin у цій конструкції - це стандартне найменування віддаленого репозиторію на локальному комп'ютері, воно може бути будь-яким, але історично його називають origin, а [gitHUB_ACCESS_TOKEN] - це токен, який можна згенерувати тут, потім потрібно повторити команду, тільки вказати git remote set-url origin, решта без змін.

  У нашому випадку команда синхронізації буде виглядати так: git remote add origin https://[email protected]/Pseudolukian/my_test_repo.git репозиторій за допомогою команди git push-u origin main. Далі для завантаження змін можна просто використовувати команду git push:

  У виведенні команди git push відображено: кількість об'єктів, що передаються, їх розмір і гілка локального і віддаленого репозиторію.Завантажити файли з віддаленого репозиторію до локального, якщо він загальний — можна командою git pull. Тепер ми вміємо працювати з локальним та віддаленим репозиторіями, настав час підбити підсумок.

  Збираємо докупи все нові знання про git і gitHUB

  Git це одна з найпопулярніших систем версіонування, розроблена Лінусом Торвальдсом для спільної роботи над Linux-ядром. Git дозволяє:

  1. Зберігати різні версії файлів та переміщатися між ними;
  2. вести розробку різного функціоналу проекту в різних гілках;
  3. Завантажувати локальні репозиторії на віддалені git-хостинги

  Git поставляється з багатьма Linux-репозиторіями, наприклад він включений у всі версії Ubuntu, починаючи з 16 версії. Також git доступний для Windows і MacOS, але для цих ОС його потрібно встановлювати вручну. Перевірити чи git у вашому Linux можна командою git --version . Про те, як встановити останню версію git, можна дізнатися звідси.

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

  Загальна схема роботи з локальним git-репозиторієм така:

  1. Створюється директорія та структура проекту за допомогою команд mkdir та touch;
  2. У корені проекту ініціалізується репозиторій командою git init;
  3. Вносяться зміни до файлів проекту і вони завантажуються в індекс репозиторію за допомогою команди git add.;
  4. Підготовлені зміни завантажуються до репозиторію командою git commit -m «Текст комміту».

  Якщо у вас великий проект, що складається з кількох логічних блоків, що вимагають індивідуального та незалежного опрацювання, доцільно вести розробку в різних гілках. Наприклад, роботу над Django-проектом можна вести у двох гілках: backend та frontend. Потім злити гілки в одну гілку main.

  Звичайно, зберігати репозиторій на локальній машині чи сервері для розробки – небезпечно, можна втратити дані. Для безпечного та віддаленого зберігання репозиторіїв існують різні git-хостинги. Один з найпопулярніших серед них – це gitHUB.

  GitHUB - це умовно безкоштовний хостинг, куди можна завантажувати репозиторії, ділитися ними, вести спільну приватну розробку та автоматизувати процес тестування та деплойменту. Багато фішок і функцій gitHUB безкоштовні або умовно безкоштовні до вичерпання певного ліміту безкоштовних ресурсів.

  Локальний та віддалений репозиторій зв'язуються між собою, і ви можете вивантажувати оновлення свого локального репозиторію буквально в одну команду. Якщо ви працюєте в команді, то також зручно отримувати оновлення загального віддаленого репозиторію та працювати з новими даними локально.

  GitHUB має багато унікальних і дуже корисних функцій. Наприклад, за допомогою gitHUB Actions ви можете налаштувати автоматичне тестування вашого проекту та його доставку на продакшн-сервер. Про те, як це зробити і що таке gitHUB Actions ми поговоримо в наступній статті, а поки що рекомендуємо ознайомитися з попередніми статтями, щоб у вас склалося повніше уявлення про те, що таке git і як з ним працювати.

  Git: встановлення, налаштування, ініціалізація репозиторію

  Розбираємось з основами git: встановлюємо git на Linux, створюємо репозиторій та робимо перші комміти.