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=[]», которая автоматически возвращает репозиторий в состояние до начала поиска или оставляет активным проблемный коммит, без необходимости отдельного запуска команды «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», и вывод подсказки по использованию корректного варианта.
Источник: habr.com