Представлен публике Git 2.56

28 сентября 2026 года мейнтейнер проекта Git Хунио Хамано (Junio Hamano) показал выпуск распределённой системы управления версиями Git 2.56 с изменениями в рамках подготовки к Git 3.0. В обновление вошли 748 изменений кода и фиксов с патчами от 104 разработчиков, 39 из них — новые участники проекта. Исходный исходник Git опубликован на GitHub под лицензией GPLv2+.

Выпуск Git 2.47 состоялся в октябре 2024 года. Релиз Git 2.48 опубликована в январе 2025 года. В середине марта 2025 года вышла версия Git 2.49. Версия Git 2.50 случилась в июне 2025 года. Сборка Git 2.51 вышла в августе 2025 года. Версия Git 2.52 произошёл в ноябре 2025 года. Версию Git 2.53 представили в феврале 2026 года. Предыдущая стабильная версия решения вышла в июне 2026 года.

Ранее в состав Git 2.52 было добавлено предупреждение о включении по умолчанию в выпуске Git 2.53 сборки компонентов на языке Rust. В версии Git 2.53 были только добавлены отдельные улучшения поддержки Rust (функция сборки без GNU sed), но сборка с Rust при использовании Makefile оставлена по умолчанию отключённой (требует выставления флага WITH_RUST), а при использовании Meson автоматически активируется при наличии компилятора rustc. В версии Git 3.0 инструментарий Rust намерены включить в число обязательных сборочных зависимостей.

По информации OpenNET, основные доработки и изменения в Git 2.56 (в целом, этот релиз сосредоточен на улучшении повседневных рабочих процессов в различных сценариях использования Git, а не на внесении одного или нескольких крупных изменений, хотя они тоже есть):

• добавлен режим «git add ‑resolved» для разрешения конфликтов при слиянии веток, который проверяет файлы на наличие маркеров конфликта и при выявлении маркера хотя бы в одном файле выдаёт ошибку, не индексирует ни один из файлов и демонстрирует список файлов требующих исправления. В отличие от команды «git add ‑update» в новом режиме обрабатываются только файлы, находящиеся в состоянии конфликта, а не связанные с конфликтом изменённые файлы игнорируются, что позволяет безопасно завершать слияние веток, даже если в рабочем каталоге находятся другие незавершённые правки (команда «git add ‑update» добавляла в индекс все ранее отслеживаемые изменённые файлы в рабочем каталоге);

• значительно ускорена работа с большими репозиториями, за счёт оптимизации алгоритма поиска последних общих коммитов при слиянии веток и сравнении коммитов. В процессе работы теперь учитываются коммиты, принадлежащие исключительно одной из веток, что позволяет остановить сканирование сразу после обнаружения всех возможных общих предков, не тратя время на дальнейший перебор истории изменений. В одном из протестированных репозиториев скорость поиска выросла в среднем в 20 раз, а в другом ускорение достигало 70 раз. При выполнении команды «git merge‑base ‑all v4.8 v4.9» в репозитории с ядром Linux количество шагов обхода уменьшилось со 167 тыс. до 3.8 тыс.;

• для серверного применения адаптирован режим перепаковки «‑path‑walk», позволяющий создавать более компактные pack‑файлы за счёт группировки объектов по их пути в дереве каталогов (в частности, для репозитория Fluent ui использование «‑path‑walk» позволило уменьшить размер pack‑файла с 558 МБ до 164 МБ). В новой версии реализована функция использования режима «‑path‑walk» совместно с битовыми картами достижимости (reachability bitmap) и дельта‑островами (delta island), применяемыми git‑хостингами для ускорения работы и изоляции форков от основного репозитория;

• устранены узкие места, приводившие к избыточным вычислениям в больших репозиториях: убраны лишние проверки состояния файлов при записи в reftable; исключено повторное сканирование списка при каждой вставке нового pack‑файла; ускорены операции с reftable, в которых накопилось много записей об удалении; оптимизирована работа «git diff» при указании ограничений по файловым путям. После внесения оптимизаций работа с reftable при большом числе удалений ускорилась в 65 раз (с 13 секунд до 0.2 секунды), а выполнение проблемной команды «git diff» в репозитории Chromium с 500 000 элементами в индексе стало занимать 0.07 секунд вместо 8 минут;

• в экспериментальную команду «git history», предоставляющую возможности для перезаписи истории изменений, добавлена операция «git history drop» для удаления выбранного коммита с автоматическим прикреплением его потомков к родительскому коммиту;

• добавлена команда «git branch ‑delete‑merged 'origin/*' 'topic‑*'» для безопасного удаления групп локальных веток, изменения из которых уже переданы во внешний репозиторий. Для фильтрации веток и репозиториев допускается использование масок. Для анализа претендентов на удаление, без фактического выполнения операции, можно использовать флаг «‑dry‑run»;

• добавлена команда «git refs create|update|delete|rename», в которой объединены низкоуровневые операции для создания, удаления, переименования и обновления ссылок;

• в команду «git bisect run» добавлена опция «‑reset‑when‑found=[<where>]», которая автоматически возвращает репозиторий в состояние до начала поиска или оставляет активным проблемный коммит, без необходимости отдельного запуска команды «git bisect reset»;

• в команду «git replay» добавлен флаг «‑linearize» для использования плоской топологии слияния, по аналогии с «git rebase ‑no‑rebase‑merges», но без обращения к рабочему дереву;

• в команде «git log ‑follow» реализовано отслеживание переименования файлов в нелинейной истории изменений, в частности, при слиянии подветок. Путь к файлу теперь фиксируется отдельно для каждого родительского коммита, что делает итог независимым от порядка обхода истории коммитов;

• добавлена функция применения команды «git repack ‑a ‑filter=blob:limit=1m ‑drop‑filtered» для удаления больших blob‑объектов, загруженных на лету (on demand) из внешнего репозитория и не используемых в текущем индексе. При обращении к этим объектам в дальнейшем они будут автоматически повторно загружены;

• в команде «git log ‑graph» для графов с несколькими независимыми корнями реализовано добавление отступов для наглядного отделения несвязанных коммитов;

• обеспечено выявление типовых опечаток, таких как указание «git push origin/main» вместо «git push origin main» или «git branch ‑set‑upstream‑to origin main» вместо «git branch ‑set‑upstream‑to=origin/main», и вывод подсказки по использованию корректного варианта.