The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Выпуск системы управления исходными текстами Git 2.54

21.04.2026 12:01 (MSK)

Представлен релиз распределенной системы управления исходными текстами Git 2.54. Git отличается высокой производительностью и предоставляет средства нелинейной разработки, базирующиеся на ответвлении и слиянии веток. Для обеспечения целостности истории и устойчивости к изменениям "задним числом" используются неявное хеширование всей предыдущей истории в каждом коммите, а также удостоверение цифровыми подписями разработчиков отдельных тегов и коммитов. Код Git распространяется под лицензией GPLv2+.

По сравнению с прошлым выпуском в новую версию принято 770 изменений, подготовленных при участии 137 разработчиков (66 впервые приняли участие в разработке Git). Основные новшества:

  • Реализована команда "git history", предоставляющая экспериментальные возможности для перезаписи истории изменений, более простые и безопасные в использовании, чем перебазирование коммитов командой "git rebase". Предоставляются две операции:
    • "git history reword <commit>" для перезаписи сообщения в указанном коммите без изменения рабочего дерева и индекса (кроме примечания, остальное остаётся нетронутым). Например, для исправления опечатки.
    • "git history split <commit>" для интерактивного разделения указанного коммита на два разных коммита с перемещением выбранных частей из исходного коммита в дополнительный коммит.

    В будущих выпусках ожидается добавление дополнительных команд: "git history fixup" для исправления коммита, "git history drop" для удаления коммита, "git history reorder" для изменения порядка следования коммитов и "git history squash" для объединения коммитов.

  • Реализован новый метод определения обработчиков (hook) в файлах конфигурации. Вместо размещения скриптов с обработчиками в каталоге ".git/hooks" в каждом репозитории, команды для вызова обработчиков теперь можно задавать непосредственно в файлах конфигурации. Настройки можно привязывать к репозиторию или указывать в файлах конфигурации, действующих для всех репозиториев (/etc/gitconfig) или репозиториев пользователя (~/.gitconfig). Возможна привязка нескольких обработчиков к одному событию. Скрипты из ".git/hooks" по-прежнему продолжают вызываться, но запускаются после обработчиков из файлов кофигурации. Для просмотра списка обработчиков следует использовать команду "git hook list", а для выборочного отключения вызова обработчиков - настройку "hook.<name>.enabled = false".
    
       [hook "linter"]
          event = pre-commit
          command = ~/bin/linter --cpp20 
    
       [hook "no-leaks"]
          event = pre-commit
          command = ~/bin/leak-detector
    
       $ git hook list pre-commit
       global    linter  ~/bin/linter --cpp20
        local    no-leaks    ~/bin/leak-detector 
    
    
  • В команде "git maintenance" по умолчанию задействована стратегия "geometric" ("git config set maintenance.strategy geometric"), позволяющая сократить время обслуживания крупных монорепозиториев. По сравнению с ранее применяемой стратегией, использующей логику как в команде "git gc", новая стратегия избегает переупаковки всех объектов и исключает излишне ресурсоёмкие операции, такие как слияние всех pack-файлов (по возможности объединение производится частями и без чистки удалённых объектов).
  • База данных объектов (ODB) и связанные с ней API переведены на новую архитектуру, основанную на использовании подключаемых бэкендов. Проведённая реструктуризация абстрагирует формат хранения объектов и в дальнейшем позволит реализовать такие возможности, как альтернативные бэкенды и форматы объектов, например, для более эффективного хранения крупных бинарных файлов или для оптимизации работы крупных git-хостингов.
  • В команде "git repo structure", выводящей сведения о структуре репозитория, обеспечено отображение не только общего размера, но и показа самых крупных объектов каждого типа, что позволяет обойтись при оценке размера без использования сторонней утилиты git-sizer.
    
       $ git repo structure
       ...
       | * Largest objects         |             |
       |   * Commits               |             |
       |     * Maximum size    [1] |   17.23 KiB |
       |     * Maximum parents [2] |      10     |
       |   * Trees                 |             |
       |     * Maximum size    [3] |   58.85 KiB |
       |     * Maximum entries [4] |    1.18 k   |
       |   * Blobs                 |             |
       |     * Maximum size    [5] | 1019.51 KiB |
       |   * Tags                  |             |
       |     * Maximum size    [6] |    7.13 KiB |
    
  • В команде "git replay", применяемой вместо "git rebase" для воссоздания истории на сервере без рабочего дерева, включено по умолчанию атомарное обновление ссылок (вместо вывода списка команд update-ref для ручного выполнения), реализована опция "--revert" для отмены изменений от серии коммитов, обеспечено отбрасывание результирующих пустых коммитов и появилась возможность воссоздания истории вплоть до корневого коммита.
  • В "git rev-list" и похожие команды добавлена опция "--maximal-only" для показа только коммитов, недостижимых другими коммитами.
  • В команду "git repo info" добавлена опция "--keys" для вывода вписка всех известных ключей.
  • В команде "git add -p" при навигации между блоками кода при помощи клавиш "J" и "K" обеспечена пометка уже одобренных и пропущенных блоков. Добавлена опция "--no-auto-advance" для отключения автоматического перехода к следующему файлу, чтобы иметь возможность вернуться к прошлым файлам перед коммитом.
  • Проведена оптимизация web-интерфейса "gitweb" для работы с мобильных устройств.
  • В команде "git apply --directory" перед использованием обеспечена нормализация файловых путей, таких как "./un/../normalized/path".
  • Документирована возможность добавления собственных подкоманд через размещение файлов "git-<cmd>" в каталоге с исполняемыми файлами.
  • В команду "git send-email" добавлена поддержка клиентских сертификатов.
  • Для команды "git status" реализована настройка "status.compareBranches", через которую можно указать ветки, с которыми будет производиться сравнение текущей ветки.
    
    [status]
       compareBranches = @{upstream} @{push}
    
  • В "git rebase" добавлена опция "--trailer" для упрощения добавления метаданных ко всем коммитам.
    
       git rebase --trailer "Reviewed-by: Test <[email protected]>"
    
  • В команду "git fast-import" добавлена возможность замены подписей для коммитов, которые стали невалидны после импорта.
  • Добавлена поддержка упаковки (compaction) многопакетных индексов MIDX (multi-pack index), при которой между собой объединяются мелкие слои MIDX-индекса c информацией о доступности объектов и связанные с ними bitmap-файлы, что позволяет уменьшить число накопившихся слоёв в давно существующих репозиториях.
  • В команде "git backfill" реализована возможность указания ревизий (диапазонов коммитов) и масок путей (pathspec) для ограничения загружаемых частей истории изменений.
    
       git backfill main~100..main
       git backfill -- '*.c'
    
  • Добавлены альтернативные формы вызова команды "git config list" - "git config -l" и "git config --list".
  • Разрешено использование не-ASCII символов в именах псевдонимов команд, задаваемых в файле конфигурации.
    
       [alias "получить"]
           command = fetch
    
  • Изменено отображение подписей, у которых истёк срок действия GPG-ключей, но которые были валидны на момент подписания коммита. Подобные подписи теперь отображаются как корректные с примечанием об устаревании ключа (ранее они подсвечивались красным цветом, что создавало впечатление об их некорректности).
  • При обращении к репозиториям по HTTP обеспечена обработка ошибки с кодом 429 (Too Many Requests). Завершившиеся подобной ошибкой запросы теперь рассматриваются не как фатальная проблема, а как временная ошибка, для которой через какое-время следует повторить операцию. Задержка перед повтором задаётся через опцию "http.retryAfter", число повторов - "http.maxRetries", время ожидания - "http.maxRetryTime".


  1. Главная ссылка к новости (https://lore.kernel.org/lkml/x...)
  2. OpenNews: Выпуск системы управления исходными текстами Git 2.53
  3. OpenNews: Утечка в Git-репозитории конфиденциальных данных, накопленных AI-ассистентами
  4. OpenNews: В Git 3.0 предложено сделать Rust обязательной частью сборочной инфраструктуры
  5. OpenNews: Уязвимости в Git, допускающие выполнение кода при обращении к внешнему репозиторию
  6. OpenNews: Доступна децентрализованная система отслеживания ошибок git-bug 0.9
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/65252-git
Ключевые слова: git
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (31) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 12:31, 21/04/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Лучшая система контроля версий ever.
     
     
  • 2.2, Аноним (2), 12:33, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/
    cvs лучше
     
     
  • 3.3, Аноним (3), 12:40, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/
    нет, рар
     
  • 3.27, Аноним (27), 14:38, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    src_yyyy.mm.dd.zip же!
     
  • 2.4, Аркагоблин (?), 12:41, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Можно подумать есть выбор. GitHub, GitLab, даже Codeberg - всё заточено на Git. Да, можно найти маргинальный сервис с чем-то другим, но если у кода не появится пользователей (а там их точно не появится!), то зачем тогда публиковать?
     
     
  • 3.21, Аноним (21), 14:11, 21/04/2026 Скрыто ботом-модератором     [к модератору]
  • +/
     
  • 2.5, Аноним (5), 12:43, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    >Лучшая система контроля версий ever.

    Нету конкурентов. BitKeeper послал ядро и Линуса, ядро и Линус послало биткипера, так появился гит.

     
     
  • 3.24, Аноним (24), 14:25, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Юникс послал гну и ядро и так появился Линукс.
     
  • 3.29, Аноним (29), 14:44, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Ой, конкурентов навалом было - инвалидный hg, маргинальные фоссилы и пихули, математичный darcs ажно основанный на patch theory. История рассудила.
     
  • 2.20, IMBird (ok), 14:09, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/
    ... называется hg.
     

  • 1.6, Sm0ke85 (ok), 12:43, 21/04/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    >Выпуск системы управления исходными текстами Git 2.54

    Заголовок не точный...

    '''
    Git — распределённая система управления Версиями.
    '''

     
     
  • 2.22, Аноним (21), 14:12, 21/04/2026 Скрыто ботом-модератором     [к модератору]
  • +1 +/
     
  • 2.30, Аноним (29), 14:45, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Изначальный заголовок правильный, версиями тут никаким боком.
     

  • 1.7, Аркагоблин (?), 12:48, 21/04/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Говорить что Git - лучшая СКВ это всё равно, что говорить что Солнце - лучшее светило. У неё монополия, все сервисы и приложения используют именно её, и она вне конкуренции.
     
     
  • 2.9, аврварвар (?), 12:55, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Новую СКВ сделать немножко проще, чем новое светило.
     
  • 2.14, Аноним (1), 13:36, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Мне плевать на монополию и какие-то там приложения, которые её используют (кстати, что это за приложения?). Я оцениваю по объективным признакам - она просто самая лучшая из тех, что существуют или когда-либо существовали: rcs, cvs, svn, fossil, hg
     
     
  • 3.15, Аркагоблин (?), 13:50, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Объективным качествам? Так древнеарамейский язык может тоже качественный, но если на нём не с кем общаться и его нельзя применить на практике, то и его качество бесполезно.
     
  • 3.17, Аноним (3), 14:00, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/
    ну т.е. реального монополиста, perforce, ты в глаза не видел?
     
     
  • 4.36, Аноним (36), 15:10, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    При MS головного мозга что угодно может привидеться.
     
  • 2.16, Аноним (16), 13:56, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Она не лучшая СКВ, но монополий там, где действуют сетевые эффекты, избежать невозможно. А в СКВ они особенно сильны. Просто все проприетарщики кроме гитхаба оказались клиническими д********и и просрали все полимеры.
     
  • 2.26, Аноним (24), 14:27, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Не посещала мысль, что монополия это плохо?
     
     
  • 3.34, Аноним (29), 14:57, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Конечно плохо, это же в первом классе рассказывают. Безусловно нужно демонополизировать и пользоваться 2-3 несовместимыми VCS.
     
  • 2.31, Аноним (29), 14:50, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > Говорить что Git - лучшая СКВ это всё равно, что говорить что Солнце - лучшее светило. У неё монополия, все сервисы и приложения используют именно её, и она вне конкуренции.

    Ну да, а монополией её сделал лично Линус, потому что ходил по домам разработчиком и сносил им другие VCS. Нет, она монополия именно потому что лучшая. У hg были все шансы, он не взлетел. У большинства VCS-новоделов есть интероп с гитом, поэтому тоже все шансы, но кто ими пользуется?

     

  • 1.8, Аноним83 (?), 12:54, 21/04/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    У меня rebase всегда какой то медленный, вот бы его ускорили.
     
     
  • 2.13, Аноним (13), 13:24, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    и зачем ты делаешь rebase?
     
     
  • 3.18, Аноним83 (?), 14:04, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Потому что у меня набор локальных патчей, и я периодически подтягиваю с апстрима свежее и мне надо чтобы мои коммиты накатились сверху.
    В одном случае их 20, в другом 60 и занимает это каждый раз как то неприлично много времени - на каждый коммит по 1 секунде примерно.
    В моём представлении там всего то надо вызывать patch, потом git add, git commit. Учитывая что оно делается внутри одного бинарника то я ожидаю что с моми диффами в 1кб оно должно работать непрелично быстро.
     
     
  • 4.32, Аноним (29), 14:53, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Тоже такое замечал на дереве портов FreeBSD (хотя это огромный реп). Стоило бы это попрофайлить, но пока недостаточно чешется.
     
  • 4.35, Аноним (35), 15:07, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    >В одном случае их 20, в другом 60 и занимает это каждый раз как то неприлично много времени - на каждый коммит по 1 секунде примерно.

    Помещаете в переменные $from указатель на последний коммит из родительской ветки, $to - последний нужный вам коммит, это можно автоматизировать, опираясь на ваш подход, после чего делаете
    git diff "$from..$to" | git apply
    git add .
    git commit -m 'one commit'
    Данная команда сожмёт всё в один коммит. Можно расписать более сложную логику, например через git log --name-only получать список имён, но это уже делать вам.

     
  • 3.28, Аноним (27), 14:40, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А ты ветки мержишь? Серьёзно?
     

  • 1.23, RM (ok), 14:24, 21/04/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    git rip?

    из текста новости

    Для обеспечения целостности истории и устойчивости к изменениям "задним числом" используются неявное хеширование всей предыдущей истории в каждом коммите,

    и ниже

    Реализована команда "git history", предоставляющая экспериментальные возможности для перезаписи истории изменений

     
     
  • 2.33, Аноним (29), 14:54, 21/04/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Ох. Тебе рассказать чем отличается локальная история от публичной? Не, иди сам почитай.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2026 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру