Git 2.56 уже доступен. В новой версии разработчики сосредоточились не на одном громком нововведении, а на большом наборе изменений, которые делают повседневную работу с репозиториями безопаснее и быстрее.

Особенно заметны улучшения вокруг merge-конфликтов, больших историй, refs, partial clone и операций, которые раньше могли неожиданно упираться в масштаб репозитория.

Ниже главное из официального обзора GitHub по Git 2.56 и то, где эти изменения действительно пригодятся в работе.

git add —resolved для безопасной фиксации конфликтов

Одно из самых практичных изменений Git 2.56 — новый режим git add --resolved.

После merge-конфликта обычно нужно сначала вручную исправить содержимое файлов, а затем добавить разрешённые файлы в индекс. Проблема в том, что привычные команды вроде git add -u могут захватить и другие изменённые отслеживаемые файлы, которые вообще не относятся к конфликту.

Новый режим работает уже точнее. Он рассматривает только пути, которые сейчас отмечены в индексе как конфликтующие. Перед добавлением обычных текстовых файлов Git также проверяет, не остались ли внутри маркеры конфликта.

git add --resolved

Если маркеры всё ещё есть, Git сообщает об этом и не добавляет выбранные файлы. Это полезная страховка в репозиториях, где параллельно с merge уже лежат локальные изменения.

Merge base стал заметно быстрее на сложной истории

Git 2.56 также оптимизирует поиск merge base. В больших монорепозиториях и историях с длинными боковыми ветками старый алгоритм мог продолжать обход уже тогда, когда новых общих предков фактически появиться не могло.

В новой версии Git раньше останавливает лишний обход графа, когда одна из сторон уже исчерпана.

В официальном материале GitHub приводятся реальные примеры, где время поиска merge base сокращалось с долей секунды до сотых, а на отдельных больших монорепозиториях ускорение измерялось десятками раз.

Для небольшого проекта разница может быть незаметной. Но на репозиториях с очень длинной историей такие оптимизации влияют уже на CI, developer tooling и команды, которые часто анализируют граф.

Экспериментальный git history получил drop

Команда git history остаётся экспериментальной, но продолжает развиваться.

В Git 2.56 появился новый вариант:

git history drop <commit>

Он удаляет выбранный commit из линейной истории и переигрывает его потомков поверх родительского commit.

При этом Git старается сохранить несвязанные локальные изменения. Операция прерывается, если перепроигрывание приведёт к конфликту или перезаписи локальной работы.

Функция пока имеет ограничения: например, она не предназначена для историй с merge commits и не позволяет удалить корневой или merge commit.

Работа с refs становится более цельной

Низкоуровневое управление ссылками в Git исторически было разбросано по разным plumbing-командам. Git 2.56 продолжает собирать такие операции под git refs.

git refs create refs/heads/topic <new-value>
git refs update refs/heads/topic <new-value> [<old-value>]
git refs delete refs/heads/topic [<old-value>]
git refs rename refs/heads/old refs/heads/new

Это именно низкоуровневые команды. Например, git refs rename переносит ref и reflog, но не выполняет все настройки ветки, которые делает обычный git branch -m.

Для автоматизации и внутренних инструментов это полезно, потому что API команд становится более последовательным и предсказуемым.

Удаление уже слитых веток стало удобнее

Ещё одно изменение касается обслуживания локальных веток.

Git 2.56 добавляет пакетный режим для удаления веток, чьи изменения уже попали в соответствующие upstream-ветки.

git branch --delete-merged 'origin/*' 'topic-*' --dry-run

Сначала можно запустить dry run и посмотреть, что именно будет удалено. Затем выполнить ту же операцию уже без --dry-run.

Это удобнее для репозиториев, где локально регулярно остаются десятки feature-веток после завершённых задач.

Partial clone теперь можно очищать от крупных восстановимых blob

Partial clone позволяет изначально не скачивать часть объектов. Но объекты, которые затем были получены по требованию, раньше оставались локально.

В Git 2.56 появилась возможность вручную удалить крупные blob, которые при необходимости можно снова получить из promisor remote.

git repack -a --filter=blob:limit=1m --drop-filtered --dry-run
git repack -a --filter=blob:limit=1m --drop-filtered

Сначала можно посмотреть кандидатов на удаление, затем выполнить очистку.

Это не автоматический ограниченный кэш, но для очень больших репозиториев такая возможность помогает контролировать локальный объём данных.

git log —follow лучше работает с нелинейной историей

Git 2.56 исправляет ещё одну старую проблему. При отслеживании переименованного файла через git log --follow результат в нелинейной истории мог зависеть от порядка обхода родителей.

Теперь путь хранится отдельно для каждого родителя, поэтому поведение становится стабильнее в случаях, когда разные ветки переименовывали один и тот же файл по-разному.

Особенно это заметно на сложной истории с subtree merge и несколькими независимыми линиями разработки.

Исправлены проблемы масштабирования

В релизе есть и ряд внутренних оптимизаций, которые убирают квадратичные участки из обычных операций.

Улучшена работа reftable, загрузка packfiles, path-limited diff и сбор untracked files. В официальном обзоре GitHub есть пример с Chromium checkout примерно на 500 тысяч записей в индексе, где одна из затронутых операций git diff после исправления сократилась с нескольких минут до долей секунды.

Такие изменения не дают новую кнопку в интерфейсе, зато хорошо показывают, почему обновление Git важно не только ради новых команд.

Git начал лучше подсказывать при типичных ошибках

Git 2.56 распознаёт несколько распространённых ошибок в синтаксисе и предлагает более вероятный вариант команды.

Например, если написать:

git push origin/main

Git может подсказать форму:

git push origin main

А для неправильной записи upstream предложит корректный вариант с --set-upstream-to=origin/main.

Это небольшая деталь, но она делает CLI дружелюбнее без автоматического изменения поведения команды.

Стоит ли обновляться на Git 2.56

Если репозитории небольшие и рабочий процесс простой, релиз не заставляет срочно менять привычки. Но обновление особенно интересно тем, кто работает с:

• большими монорепозиториями;
• частыми merge-конфликтами;
• partial clone;
• автоматизированным управлением refs и branches;
• длинной и сложной историей;
• CI/CD, где Git-операции выполняются сотни раз в день.

Самым простым новым инструментом для ежедневной работы выглядит git add --resolved. Он решает понятную проблему: после конфликта добавить именно разрешённые файлы и не затронуть лишние локальные изменения.

Что это значит для автоматизации

Git всё чаще становится не только инструментом разработчика в терминале, но и основой автоматических workflow, CI, код-агентов и внутренних платформ.

Поэтому ускорение графовых операций, более аккуратные команды для refs и предсказуемое поведение в сложной истории хорошо сочетаются с автоматизацией через GitHub Actions.

А если процесс уже включает AI review, можно дополнительно посмотреть материал про Copilot Code Review через API.

Официальный источник

GitHub Blog — Highlights from Git 2.56