Содержание
Коротко
Проект Git выпустил версию 2.55: в ней есть изменения и для огромных репозиториев, и для повседневной работы с веткой. В релизе участвовало более ста разработчиков, тридцать три — впервые.
Самые заметные новшества: обслуживание набора пакетов стало бережнее к метаданным, проиндексированные изменения можно перенести в ранний коммит одной командой, а независимые проверки перед коммитом способны выполняться одновременно.
Что произошло
Git хранит коммиты, деревья и содержимое файлов как объекты. Обычно они упакованы в сжатые файлы пакетов; со временем в активном репозитории таких файлов становится много после получения изменений, отправки веток и служебных операций.
Общий индекс нескольких пакетов помогает быстро найти объект, но раньше его обновление могло требовать переписать большой файл целиком. Версия 2.55 умеет создавать цепочку добавочных индексов через git repack --write-midx=incremental, обновляя прежде всего свежую часть данных.
Цепочка не растёт бесконечно: вместе с геометрической переупаковкой система периодически объединяет соседние небольшие слои. Так старые крупные данные остаются нетронутыми, а обслуживание не превращается ни в постоянную полную запись, ни в длинную цепь мелких файлов.
В экспериментальном семействе git history появилась команда git history fixup <commit>. Она берёт уже подготовленные в индексе изменения, вносит их в выбранный ранний коммит и заново применяет последующие коммиты.
Это сокращает привычный путь из создания временного коммита и запуска git rebase --autosquash. Команда намеренно осторожна: при конфликте она прекращает работу, а в репозитории без рабочей копии не запускается, поскольку ей нужны индекс и рабочая копия.
Почему это важно
Для больших монорепозиториев стоимость служебных операций заметна не только по времени, но и по объёму записи на диск. Добавочные многопакетные индексы позволяют обслуживать новые пакеты без переписывания описания всего хранилища при каждом запуске.
Есть и ускорения для запросов достижимости объектов — основы многих операций обхода истории. В тестах из серии изменений создание битовых карт в одном крупном репозитории сократилось примерно с 612 до 294 секунд.
Пользовательские улучшения не сводятся к скорости. Если исправление по смыслу относится к раннему коммиту серии, новая команда выражает именно это намерение и избавляет историю от промежуточного служебного коммита.
Система также разрешила одновременно запускать совместимые проверки, заданные в конфигурации. Например, независимые проверка стиля и модульные тесты перед коммитом могут работать параллельно, тогда как проверки, использующие общую рабочую копию, по-прежнему выполняются по очереди.
На практике
Начинать стоит с обновления локальной установки и просмотра заметок к релизу: часть новшеств рассчитана на большие или давно живущие репозитории. Необязательно сразу менять существующие сценарии обслуживания.
Команды, которые часто правят серию коммитов перед проверкой, могут отдельно испытать git history fixup в копии ветки. Поскольку возможность помечена экспериментальной, важно проверить поведение на своих типах изменений и конфликтах.
- Для крупных репозиториев проверьте пробный запуск
git repack --write-midx=incremental; геометрический режим подключайте после измерений. - Если у вас настроены проверки перед коммитом, разделите независимые задачи и включайте параллельность только там, где они не меняют одни и те же файлы.
- На Linux оцените встроенное наблюдение за файловой системой: оно ускоряет
git status, но очень большим деревьям может понадобиться увеличить лимитfs.inotify.max_user_watches. - Для частичных копий изучите сочетание
git pack-objects --path-walkс фильтрами: в тесте исходного проекта пакет без содержимого файлов оказался примерно на 16% меньше ценой более долгого расчёта дельт.
Есть и небольшие, но полезные дополнения. Релиз маскирует большинство управляющих символов в сообщениях удалённой стороны, умеет отправлять ветку в группу удалённых хранилищ и ограничивать ширину графа истории через --graph-lane-limit=<n>.
Итог
Версия 2.55 не меняет базовую модель работы с системой контроля версий, но снимает несколько давних трений. Крупные хранилища получают более аккуратное обслуживание, а разработчики — более прямой способ исправить серию коммитов.
Для большинства команд разумный первый шаг — обновиться и выбрать одну возможность для локальной проверки. Особого внимания заслуживают добавочные многопакетные индексы для тяжёлых репозиториев и параллельные проверки там, где время перед коммитом уже стало заметным.

