Git 2.56.0 вышел 28 сентября 2026 года и добавил команду git add --resolved, которая помогает завершать слияния без случайного добавления посторонних изменений. Релиз ускоряет поиск общих предков коммитов, расширяет инструменты для очистки репозиториев и продолжает подготовку к Git 3.0.
Слияние двух веток закончилось конфликтом. Разработчик исправил проблемный файл, выполнил привычное git add -u — и вместе с исправлением отправил в индекс другие незавершённые правки. Именно для таких ситуаций в Git 2.56 появилась отдельная команда. Впрочем, изменения затронули и операции, которые пользователь обычно даже не замечает: поиск общих предков веток, хранение объектов и обработку больших рабочих каталогов.
По официальному объявлению проекта Git, над версией 2.56.0 работали 104 участника, включая 39 новых. Со времени выхода Git 2.55 в июне накопилось 748 коммитов, не считая коммитов слияния.
git add --resolved добавляет только файлы с разрешёнными конфликтами
При слиянии веток Git останавливается, когда обе стороны изменили один и тот же участок файла и программа не смогла автоматически выбрать результат. После ручного исправления файл нужно добавить в индекс — область, из которой формируется следующий коммит. До сих пор разработчики нередко применяли git add -u или git add -A, захватывая заодно изменения, не связанные с конфликтом.
Новый режим работает с путями, которые Git пометил как конфликтующие. Перед добавлением текстовых файлов он ищет оставшиеся маркеры конфликта: <<<<<<<, === и >>>>>>>. Если такие маркеры обнаружены хотя бы в одном из выбранных файлов, команда останавливается, сохраняя индекс без изменений.
git add --resolvedПредставим, что конфликт возник в config.php, а в README.md остались черновые правки. После исправления config.php новая команда подготовит к коммиту только разрешённый конфликт; изменения в README.md останутся в рабочем каталоге. При необходимости выбор можно ограничить конкретным путём.
Для удалённых файлов и двоичных конфликтов проверка текстовых маркеров неприменима, поэтому Git обрабатывает их отдельно. Режим --resolved нельзя объединить с -u или -A. Подробное поведение описано в официальных примечаниях к Git 2.56.
Поиск общего предка двух веток стал заметно быстрее
Git часто приходится искать коммит, от которого разошлись две ветки. Такой общий предок нужен для слияний, сравнения изменений и вычисления различий в запросах на включение кода — pull request и merge request.
Раньше обход истории иногда продолжался уже после того, как найти дополнительные общие предки становилось невозможно. В Git 2.56 алгоритм отслеживает оставшиеся коммиты, доступные исключительно с каждой из двух сторон. Когда одна из этих групп исчерпана, поиск может завершиться без потери корректности.
Эффект зависит от формы истории. В опубликованных GitHub измерениях для одного большого репозитория время отдельного обхода сократилось с 0,68 до 0,01 секунды. В тестовом случае с историей ядра Linux команда git merge-base --all v4.8 v4.9 вместо 167 441 шага выполнила 3 887; время уменьшилось с 0,29 до 0,01 секунды. Это результаты конкретных тестов, а не обещанное ускорение любой операции Git.
Объединённые ветки теперь можно удалять по заданному правилу
После завершения задач в локальном репозитории часто накапливаются десятки веток с устаревшими названиями. Git 2.56 добавил git branch --delete-merged: команда находит локальные ветки, чьи конечные коммиты уже содержатся в соответствующих отслеживаемых ветках.
git branch --delete-merged 'origin/*' 'topic-*' --dry-runВ этом примере первый шаблон ограничивает поиск ветками, связанными с удалённым репозиторием origin, второй отбирает локальные названия с префиксом topic-. Ключ --dry-run показывает кандидатов без удаления. Без него Git удаляет подходящие ветки, пропуская, в частности, те, что используются в другом рабочем дереве или не имеют нужной отслеживаемой ветки.
В экспериментальной команде git history появилась операция drop. Она удаляет выбранный коммит из истории и повторно применяет последующие коммиты к его родителю — действие, для которого обычно использовали интерактивный git rebase -i. Функция пока не работает с историей, содержащей коммиты слияния, и не позволяет удалить корневой коммит.
Для низкоуровневого управления ссылками Git расширили git refs: появились подкоманды create, update, delete и rename. Они рассчитаны прежде всего на инструменты автоматизации. Например, git refs rename перемещает ссылку и её журнал изменений, но не обновляет настройки ветки так, как это делает git branch -m.
Большие репозитории получили экономию места и меньше лишних операций
Git хранит содержимое файлов, деревья каталогов и коммиты в собственной базе объектов. Когда проект годами развивается, эта база может занимать гигабайты. Команда git repack переупаковывает объекты, используя сходство между версиями файлов.
Ранее режим --path-walk, который группирует объекты по путям, имел ограничения при совместной работе с битовыми картами достижимости и механизмом delta islands. Git 2.56 устранил эти ограничения. Теперь хостинги репозиториев могут испытывать более компактную переупаковку, сохраняя механизмы ускоренного поиска объектов и ограничения между их группами.
В тесте, опубликованном GitHub 28 сентября, обычная переупаковка репозитория Fluent UI создала пакет размером 558,5 МБ, а вариант --path-walk — 164,4 МБ. Снижение составило около 71% в условиях этого эксперимента. Режим по-прежнему не включён по умолчанию.
Изменения затронули и частичные клоны — локальные копии, которые сначала загружают лишь часть объектов, а остальное получают с сервера по запросу. Раньше скачанные позднее крупные файлы оставались на диске. Новый параметр --drop-filtered у git repack позволяет вручную удалить такие объекты, если их можно безопасно получить снова.
git repack -a --filter=blob:limit=1m --drop-filtered --dry-runКоманда с --dry-run предварительно показывает кандидатов. Реальное удаление требует сервера, который гарантирует повторную выдачу недостающих объектов; Git также защищает объекты, нужные текущему индексу. Пока механизм поддерживает ограничение blob:limit, а автоматического управления размером локального кэша в нём нет.
Просмотр истории переименованных файлов стал точнее
Команда git log --follow помогает проследить историю файла после переименования. В сложной истории, где разные ветки меняли его имя по-разному, прежний алгоритм мог выбрать путь в зависимости от порядка обхода коммитов.
В Git 2.56 сведения о пути хранятся отдельно для каждого родительского коммита. Результат становится независимым от того, какую ветку Git исследовал первой. Для разработчиков, разбирающихся в старых изменениях после многочисленных слияний, это уменьшает риск потерять часть истории файла.
Появились и менее заметные ускорения. В одном из тестов на рабочей копии Chromium с примерно 500 тысячами записей индекса определённый вариант git diff сократил время выполнения примерно с восьми минут до 0,07 секунды. Этот результат связан с устранением неэффективного повторного обхода записей индекса; он относится к конкретному сценарию сравнения, а не ко всем вызовам git diff.
Git 2.56 расширяет инструменты для проверки и автоматизации
Команда git bisect последовательно проверяет коммиты, помогая найти изменение, после которого появилась ошибка. Новый параметр --reset-when-found позволяет автоматически завершить сеанс поиска и вернуться к первоначальному состоянию, когда проблемный коммит найден. Вариант found завершает поиск, сохраняя переход к найденному коммиту.
Экспериментальная git replay получила параметр --linearize. Он воспроизводит изменения одной линией и пропускает коммиты слияния, подобно поведению git rebase --no-rebase-merges, без необходимости использовать рабочий каталог. Для серверных инструментов это ещё один способ перерабатывать историю без обычного переключения файлов.
У git cat-file --batch-command появилась операция remote-object-info. С её помощью клиент частичного клона может запросить размер и тип удалённого объекта по протоколу Git v2, не скачивая содержимое целого файла. Это применимо, например, при оценке объёма крупного файла модели или архива в репозитории.
Подготовка к Git 3.0 продолжается параллельно с релизом 2.56
Выход Git 2.56 совпал с обсуждением будущего Git 3.0 на конференции Git Merge 2026 в Лиссабоне. По сообщению команды GitLab от 28 сентября, участники обсуждали переход на SHA-256 как формат хеширования по умолчанию, хранилище ссылок reftable и обязательное использование Rust при сборке будущей основной версии.
В опубликованном плане после Git 2.56 намечен переход к версии 2.98 в декабре 2026 года, а выпуск 2.99 и 3.0 обсуждается на весну 2027-го. Git 2.99 предполагается оставить версией с длительной поддержкой для платформ без инструментария Rust. Это план, озвученный после встречи участников проекта; конкретные условия и сроки ещё могут уточняться в обсуждениях разработчиков.
Пока Git 2.56 сохраняет привычную модель работы с репозиториями. Его изменения уже доступны в повседневных командах, тогда как переход на новые значения по умолчанию для формата хешей и хранилища ссылок остаётся задачей следующего крупного выпуска.
