Открытый проект Git выпустил версию Git 2.56. GitHub представил обзор ключевых нововведений и изменений по сравнению с релизом 2.55.
Git 2.56.0 включает исправления и новые возможности от 104 контрибьюторов, из них 39 участвуют впервые. В обзоре выделены улучшения работы с конфликтами слияния, оптимизация поиска общих предков коммитов и развитие подхода path-walk для упаковки объектов.
При разрешении конфликта слияния есть два шага: сначала разработчик правит файлы в рабочем каталоге так, чтобы в каждом конфликтующем пути был нужный результат, затем индексирует эти пути, помечая конфликт как решённый. На этом этапе прежние команды легко могли добавить в индекс лишние изменения: git add -u индексирует все изменённые отслеживаемые файлы, включая правки, не связанные с конфликтом, а также файлы, в которых могли остаться маркеры конфликта.
Новый режим git add –resolved специально создан для безопасного завершения этого шага. Он учитывает только пути, которые сейчас числятся конфликтными в индексе. Перед индексированием команда просматривает такие обычные файлы на предмет текстовых маркеров конфликта; если их находит, сообщает о проблемных путях и оставляет индекс без изменений.
В коротком выводе git status –short теперь проще увидеть результат: файл с рецептом уже помечен как решённый и проиндексирован, а несвязанные правки в notes.txt остаются неиндексированными. При этом можно передать pathspec, чтобы ограничить набор обрабатываемых путей. Проверка на наличие маркеров действует в пределах выбранных файлов: если хотя бы один из них содержит маркеры, не будет проиндексирован ни один.
Удаления и двоичные конфликты не содержат текстовых маркеров, поэтому git add –resolved может индексировать их как обычно. Режим работает заметно уже, чем git add -u или git add -A: его нельзя сочетать с ними, а отслеживаемые файлы, в которых не было конфликтов, он игнорирует. Такой подход снижает риск ошибок в сценариях, когда слияние начинается в рабочем каталоге, где уже есть сторонние локальные изменения.
Многие операции Git опираются на поиск наилучших общих предков двух коммитов. На них строятся алгоритмы слияния, трёхточечные сравнения, а также расчёты, которые выполняют хостинги репозиториев для диффов pull request, оценок сливаемости, диапазонов для обзора изменений и других сравнений.
Git находит такие предки, двигаясь назад по истории с обеих вершин: можно представить, что все коммиты, достижимые с одной стороны, помечаются синим цветом, а с другой — красным. Коммит, достижимый с обеих сторон, становится кандидатом на merge-base. Одного кандидата бывает недостаточно: при «перекрёстных» слияниях может быть несколько базовых коммитов, и ни один из них не является предком другого, поэтому Git должен продолжать обход, пока не будет уверен, что нашёл все варианты.
Старое условие остановки могло долго обрабатывать «хвост» старой общей истории, уже не влияющей на список merge-base. В Git 2.56 добавлен учёт количества коммитов в очереди, которые помечены цветом только с одной стороны. На концептуальном уровне, как только один из «исключительных» наборов исчерпан, новых точек пересечения в рамках этой пары вершин уже не появится, и обход можно остановить, при этом результат по-прежнему содержит все нужные merge-base.
Выигрыш по производительности заметен на старых ветках, уже слитых в сильно выросшую историю. В одном из реальных монорепозиториев время обхода сократилось с 0,68 секунды до 0,01 секунды. В боевых замерах на двух крупных монорепозиториях зафиксированы многочисленные случаи ускорения примерно в 70 раз в одном случае и средний прирост около 20 раз в другом.
Итоговая серия также закрыла давнюю проблему производительности для ядра Linux. При стандартном v2 commit-graph команда git merge-base –all v4.8 v4.9 сократилась с 167 441 шага обхода и 0,29 секунды до 3 887 шагов и 0,01 секунды.
При переупаковке репозитория Git ищет похожие объекты, которые выгодно хранить в виде дельт. Классический подход группирует кандидатов по хэшу имени. Режим path-walk вместо этого обходит объекты по их расположению в дереве, что лучше собирает вместе версии одного и того же пути и часто даёт более удачные дельты.
Потенциальная экономия на хранилище велика. В тесте с свежим клоном репозитория Fluent UI и принудительным пересчётом дельт обычная переупаковка с битовыми картами сформировала пакет размером 558,5 МБ. Переупаковка с –path-walk дала пакет 164,4 МБ, то есть примерно на 71% меньше.
Однако крупным хостингам важен не только размер пакетов. Они активно используют битовые карты достижимости для быстрых перечислений объектов, а некоторые применяют delta islands, чтобы объекты из одной группы ссылок не зависели от объектов, доступных только из другой. Ранее path-walk был несовместим с обоими подходами, что ограничивало его применение.
Git 2.56 снимает эти ограничения. Переупаковка в режиме path-walk теперь может формировать новый набор битовых карт. Поздние вызовы git pack-objects могут использовать уже построенную битовую карту там, где она даёт ответ, и переходить к обходу по path-walk только при необходимости.
Path-walk также теперь ведёт учёт, необходимый для delta islands: распространяет принадлежность к «островам» по коммитам и деревьям до выбора баз для дельт. Это позволяет хостингам сохранять правила изоляции, одновременно проверяя эффект от более компактного хранения объектов.
Эти изменения не включают path-walk по умолчанию, но убирают два серьёзных барьера для внедрения. Крупные площадки теперь могут экспериментировать с экономией места, не отказываясь от быстрых операций с битовыми картами и ограничений delta islands.
В релиз 2.56 вошли и другие изменения и улучшения. Подробный список доступен в официальных заметках к выпуску, а также в истории предыдущих версий в репозитории Git.
Автор обзора, Элайджа Ньюрен, — старший инженер-программист в GitHub. Он разработал и реализовал merge-ort, стратегию слияния по умолчанию в Git с версии 2.34, является автором git-filter-repo (рекомендуемого проектом Git инструмента для переписывания истории) и одним из ключевых участников развития sparse-checkout.
Источник: материалы GitHub о выпуске Git 2.56 и сопутствующей аналитике.
