Систему контролю версій і зберігання програмного коду Git було розкритиковано через нібито недолік, повідомляє DevOps.com.
Йдеться про функціональну проблему, яка виникає внаслідок розрахунків Git щодо змін між різними версіями одного й того ж файлу, що зрештою призводить до зростання репозиторію через надмірні вимоги до зберігання.
Старший інженер корпорації Джонатан Кремер публічно висловився щодо проблеми зростання обʼєму коду, пов’язаної з великим репозиторієм JavaScript, з яким працює його команда. Насправді репозиторій є єдиним монорепозиторієм, і код для кількох проєктів зберігається в одному репозиторії.
«Нещодавно ми перевищили позначку у 1000 активних користувачів на місяць, орієнтовно 2500 пакетів і приблизно 20 мільйонів рядків коду! Останнє клонування цього репозиторію, яке я зробив, становило вражаючі 178 ГБ. Однак я помітив, що гілку стає все важче клонувати, оскільки вона постійно зростає», — написав Кремер у своєму блозі.
Контриб’ютор Git Деррік Столі, який також працює як головний інженер-програміст у Microsoft, пояснив ситуацію. Він зазначив, що коли Git порівнює два файли з поширеною назвою (у наведеному випадку це був CHANGELOG.md), то починає порівнювати файли з різних пакетів. Це і призвело до того, що Git виявив значну різницю з кожним комітом коду.
«Деякі репозиторії зростають набагато більше, ніж очікувалося, враховуючи кількість контриб’юторів. Є кілька причин, чому це зростання настільки значне. Основна проблема полягає в тому, що дельти не обчислюються для об’єктів, які з’являються одним шляхом. Хоча розмір цих файлів на кінцевій стадії є одним з аспектів зростання, який міг би запобігти вказаній проблемі, зміни в цих файлах повинні забезпечити хорошу компресію дельт. Проте Git не виявляє зв’язків між різними версіями одного й того ж файлу», — йдеться у повідомленні.
Збільшення репозиторіїв
Технічний інженер GitGuardian Томас Сегура вважає, що дизайн протоколу Git створює особливу проблему безпеки. Коли секрети потрапляють у коміти, вони зберігаються в історії репозиторію навіть після видалення, стаючи тим, що його компанія любить називати «зомбі».
На відміну від традиційних вразливостей під час виконання, які можна виправити, ці секрети залишаються загрозою, поки їх не відкличуть.
«Ефективне управління розміром репозиторію є важливим, особливо в монорепозиторіях, де кожен гігабайт має значення. Така помилка може підірвати переваги підтримання кращих практик, що запобігають «роздуванню» репозиторіїв до величезних розмірів. Наприклад, не комітити непотрібні або дорогі медіафайли. Це ефективне управління стосується не лише зберігання. Також це важливо для уникнення тривалого часу клонування та повільних збірок, що знижує продуктивність», — зазначив представник компанії VictoriaMetrics, яка займається моніторингом інструментів і базами даних часових рядів.
Регулярний перегляд репозиторію
Проблеми, такі як колізії імен-гешів, нагадують, що є випадки, коли навіть надійні інструменти демонструють неефективность. Регулярні аудити та перегляди репозиторіїв допомагають виявляти ці неефективності, зберігаючи продуктивність на правильному рівні й запобігаючи фрустраційним затримкам у процесі розробки.
«Ми на власному досвіді бачили труднощі, які виникають при управлінні великими репозиторіями Git. Особливо коли є багато контриб’юторів і висока швидкість змін. Розмір цих репозиторіїв може споживати надмірний обсяг дискового простору і сповільнювати операції. Є і ще одна більш нагальна проблема: підвищений ризик пошкодження, конфліктів злиття, перезаписів і помилок примусового злиття. Одна помилка контриб’ютора або адміністратора може призвести до серйозних наслідків. Це може означати втрату інтелектуальної власності або навіть втрату розуміння того, як налаштована ваша інфраструктура», — зауважив Суббія Сундарам, старший віцепрезидент із продуктів у Hycu, Inc.
Сундарам і його команда зазначили, що втрати даних у цих середовищах трапляються частіше, ніж хотілося б. Один із варіантів вирішення — це клонування репозиторію (наприклад, «final_final_final_I_promise_its_final»). Проте з численними контриб’юторами та непослідовними практиками клонування це не є безпрограшним варіантом.
Що робити, щоб зменшити ризики:
- Збільшити заходи захисту і впровадити хуки Git і контроль доступу, щоб запобігти несанкціонованим або небезпечним діям.
- Використовувати безперервну інтеграцію, щоб автоматизоване тестування й інтеграційні пайплайни могли рано виявляти проблеми, перш ніж вони стануть більшими.
- Створювати часті й заплановані резервні копії. Тобто мати узгоджені резервні копії, а не клони репозиторіїв, що дає змогу командам легше відновлюватися у випадку втрати даних.
Наразі немає офіційних коментарів від Git щодо того, чи може платформа запропонувати інструменти автоматизації для моніторингу й виправлення зазначених проблем. Хоча враховуючи збільшення обсягів обчислювальних середовищ і зростання складності кодових баз, можна очікувати деякі корективи або доповнення у майбутньому.
Читайте також на ProIT: корпорація Microsoft знову відклала розгортання своєї суперечливої функції Recall для ПК Copilot Plus.
Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!
