Git 2.55: Нові можливості для користувачів Linux та покращення продуктивності

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

Підтримка FSMonitor на Linux у Git 2.55

Для користувачів Linux найвідомішою функцією є підтримка вбудованого демона файлового монітора Git. Раніше демона FSMonitor було доступно лише на macOS і Windows. Git 2.55 додає підтримку Linux, використовуючи підсистему inotify ядра для відстеження змін файлової системи.

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

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

Покращення обслуговування репозиторіїв у Git 2.55

Git 2.55 також вводить покращення в обслуговуванні репозиторіїв, зокрема для великих проєктів. Версія дозволяє git repack створювати інкрементальні ланцюги багатопакетних індексів за допомогою git repack --write-midx=incremental.

Новий експериментальний команд git history fixup <commit> дозволяє користувачам застосовувати стадійовані зміни безпосередньо до попереднього коміту та повторно відтворювати наступні коміти.

Це надає більш прямий альтернативний спосіб до git commit --fixup і git rebase --autosquash. Проте команда залишається експериментальною; якщо застосування стадійованої зміни викликає конфлікт, Git відміняє дію замість того, щоб залишити користувача у складному стані перепису.

Покращення конфігурованих хуків

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

Наприклад, незалежні перевірки перед комітом, такі як лінтування та модульні тести, тепер можуть виконуватися одночасно, якщо вони позначені як безпечні для паралельного виконання. Хуки, які залежать від загального стану, продовжують виконуватися послідовно.

Покращення продуктивності та нові можливості

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

Додатково, часткові клонування та фільтровані пакети виграють від покращень у git pack-objects --path-walk. У Git 2.55 цей режим можнаПоєднати з фільтрами, такими як blob:none та інші.

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

Безпечніше управління гілками в Git 2.55

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

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

Введення нових параметрів для візуалізації історії

Для користувачів, які покладаються на візуальний вивід історії, команда git log --graph тепер включає опцію --graph-lane-limit=<n>. Ця опція обмежує ширину графіка, замінюючи дороги, які виходять за межі ліміту, на ~, що робить широку історію більш читабельною в терміналі.

Нарешті, Git 2.55 впроваджує параметр --max-count-oldest=<n> для git rev-list та команди git log. На відміну від параметра -n, який обирає останні коміти, цей параметр вибирає найстаріші коміти в діапазоні без обробки на стороні оболонки.

Детальнішу інформацію можна знайти в офіційному оголошенні.