Кілька способів оптимізації роботи з Git

В нашому блозі на Хабре ми розповідаємо про різні технології зі світу IaaS і не тільки. Наприклад, нещодавно ми публікували матеріал з програмним реалізаціям VPN [Частина 1; Частина 2, розповідали про DNS. Сьогодні нам би хотілося заглибитися в тему розробки додатків і сервісів і поговорити про таку річ, як Git, зокрема, про способи оптимізації роботи з ним.


/ фото hackNY.org CC


Хотілося б почати з самого початку, що ж таке Git? Git – це одна з систем управління версіями (version control system, або СКВ), на основі якої побудовані кілька сервісів, таких як GitHub або GitLab. З допомогою Git було розроблено велика кількість програмного забезпечення, яке, ймовірно, вам добре знайоме: це і ядро Linux, Firefox, а також Chrome.

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

Одна з основних завдань Git – уникнути ситуації з плутаниною між версіями продукту, коли з'являються файли з іменами на зразок project_betterVersion.kdenlive або project_FINAL-alternateVersion.kdenlive і т. д.

Щоб спростити роботу з цими файлами і потрібні системи СКВ. Так кожен член команди має можливість працювати над останньою версією проекту, вносити свої зміни і повідомляти про це колегам.

Системи контролю дозволяють зберігати декілька варіацій одного й того ж документа і при необхідності «відкочувати» його до більш ранньої реалізації. Тобто ви можете зробити копію репозиторію і працювати з нею локально, а потім за допомогою спеціальних команд впровадити свої правки (push) в основну версію або вилучити (pull) зміни, зроблені колегами.

Підвищення продуктивності
При роботі над великими продуктами постійно відбувається перейменування вихідного, виділення нових гілок, виконується порівняння з минулими версіями. Тому в досить великих проектах може спостерігатися зниження продуктивності роботи Git. З такими проблемами, як-то раз зіткнулася навіть компанія Facebook.

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

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

Зменшення репозиторію
RoR-розробник Стів Лорек (Steve Lorek) у своєму блозі пише про те, що йому вдалося скоротити розмір репозиторію з 180 МБ до 7 МБ. Для цього він спочатку створив локальну копію Git, а потім знайшов файли, що займають занадто багато місця в сховищі. Тут на допомогу прийшов bash-скрипт Ентоні Стаббса (Antony Stubbs), який знаходить 10 найбільших і непотрібних файлів.

Після цього він видалив ці файли, скориставшись серією команд:

$ git filter-branch --tag-name-filter cat --index-filter 'git rm -r --cached --ignore-unmatch filename' --prune-empty -f -- --all
$ rm -rf .git/refs/original
$ git reflog expire --expire=now –all
$ git gc --prune=now
$ git gc --aggressive --prune=now

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

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

При зеркалировании настроюється один або кілька активних дзеркальних серверів, які виконують тільки операції читання копій репозиторіїв і синхронізуються з основним примірником. Такий підхід дозволяє скоротити час передачі копії репозиторію на 5 ГБ приблизно в 25 разів.

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

Також варто відзначити розширення Git Large File Storage (Git LFS), яке пише в репозиторій вказівники на файли. Операції з цими файлами відстежуються за допомогою фільтрів clean і smudge, а їх вміст зберігається на віддаленому сервері GitHub.com або GitHub Enterprise. Опис декількох інших утиліт ви можете знайти на посилання.

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

git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.ci commit
git config --global alias.st status

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

git config --global alias.l "log --oneline --graph"

Конкретно у цьому випадку ви отримаєте можливість виводити логи в рядок і у графічному вигляді командою git l.

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

P. S. А ще ми пишемо про створення нашого IaaS-провайдера 1cloud:


Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.