Выпуск распределенной системы управления исходными текстами Git 2.19
Подготовлен выпуск распределенной системы управления исходными текстами Git 2.19.0. Git является одной из самых популярных, надёжных и высокопроизводительных систем управления версиями, предоставляющей гибкие средства нелинейной разработки, базирующиеся на ответвлении и слиянии веток. Для обеспечения целостности истории и устойчивости к изменениям задним числом используются неявное хеширование всей предыдущей истории в каждом коммите, также возможно удостоверение цифровыми подписями разработчиков отдельных тегов и коммитов. По сравнению с прошлым выпуском в новую версию принято 769 изменений, подготовленных при участии 72 разработчиков, из которых 16 впервые приняли своё участие в разработке.
Основные новшества:
- Добавлена команда «git range-diff», позволяющая сравнить разные наборы коммитов. В отличие от «git diff» команда «git range-diff» может охватить более одного коммита и показать не только изменения содержимого и прикреплённых примечаний, но и различия в порядке следования коммитов. Например, новая команда может применяться для оценки различий между состоянием сразу нескольких коммитов после корректировки набора исправлений при помощи «git rebase» в процессе подготовки к слиянию с основным проектом.
На скриншоте ниже показано изменение состояния веток, при котором коммит с добавлением README.md перемещён на первое место, внесено исправление в один из коммитов, исправлено примечание и добавлен дополнительный коммит, вставляющий недостающий символ перевода строки:
- В команду «git grep» добавлены новые опции »--column» и »--only-matching» (»-o»). При указании »--column» в выводе кроме номера строки также показывается и номер позиции совпадения в строке. Данную информацию можно использовать в новом дополнении git-jump для Vim, применяемого для точного перехода на искомую позицию в файле при разборе конфликтов слияния, просмотре различий и выполнении операции поиска.
Опция »--only-matching» может применяться для отображения только части строки, подпадающей под заданное регулярное выражение. Например, для подсчёта частоты использования в коде разных вариантов именования хэшей SHA-1 можно использовать команду:
- В командах работы с ветками, такими как «git branch», «git tag» и «git for-each-ref», предоставляется опция »--sort», позволяющая определить порядок вывода результатов. В новом выпуске дополнительно предложен параметр «branch.sort», позволяющий определить в файле конфигурации метод сортировки по умолчанию. По умолчанию осуществляется сортировка по имени (refname), но для некоторых разработчиков удобнее метод «authordate», при котором выполняется сортировка по времени последнего обновления (вначале выводятся самые свежие ветки). Также доступны методы сортировки «numparent» (по числу привязок) и «upstream» (по серверам, с которых были получены ветки);
- Обеспечена автоматическая генерация списка автодополнения ввода для большинства команд и опций файла конфигурации;
- В функциях создания и верификации цифровых подписей для коммитов и тегов появилась поддержка применения утилиты gpgsm, которая используется сертификаты X.509 вместо ключей OpenPGP;
- Опция »-l» в «git branch», которая является сокращением опции »--create-reflog», объявлена устаревшей и теперь приводит к выводу предупреждения. В будущем планируется сделать »-l» сокращением опции »--list», по аналогии с командой «git tag -l»;
- Добавлена настройка checkout.defaultRemote, позволяющая определить удалённый сервер, используемый по умолчанию для выполнения операции checkout с именем внешней ветки, в случае если данная ветка присутствует одновременно на нескольких серверах;
- При помощи атрибута working-tree-encoding теперь можно задать желаемую кодировку текста в привязке к отдельным файлам, что позволяет решить проблемы с обработкой UTF-16 как бинарных данных. При установке атрибута данные будут хранится в UTF-8, но при операции checkout отдаваться в желаемой кодировке, т.е. корректно будут работать такие команды, как «git diff»;
- Добавлена экспериментальная возможность частичного клонирования репозиториев, позволяющая организовать работу не имея полной копии всего репозитория и без всей истории изменений. Например, при работе с небольшой частью очень большого репозитория частичное клонирование позволит при операциях clone и fetch ограничиться загрузкой только среза необходимых данных, без блобов и лишних веток. В дальнейшем, при обращении к отсутствующим объектам, данные объекты будут на лету загружаться с сервера по мере необходимости. Большинство внешних серверов пока не поддерживают частичное клонирование, но для локальных экспериментов можно использовать команду «git clone --filter=blob: none»;
- Представлена экспериментальная возможность хранения объектов в форме графа коммитов, при котором для индексации используется не линейный список хэшей объектов со ссылками на другие объекты, а древовидная структура в виде графа. Если сейчас для определения релизов в которых содержится определённое исправление требуется загрузка каждого объекта с диска для поиска ссылок, то при хранении в виде графа можно сразу определить все необходимые связи. Для включения нового метода хранения можно использовать команду «git config core.commitGraph true». Тестирование нового метода хранения с репозиториями ядра Linux, Git и Windows показало почти двухкратное увеличение производительности операций с ветками:
Команда До После Изменение Linux: git merge-base master topic 0.52 0.06 -88% git branch --contains 76.20 0.04 -99% git tag --contains 5.30 0.03 -99% git tag --merged 6.30 1.50 -76% git log --graph -10 5.90 0.74 -87% Git: git merge-base master topic 0.10 0.04 -60% git branch --contains 0.76 0.03 -96% git tag --contains 0.70 0.03 -96% git tag --merged 0.74 0.12 -84% git log --graph -10 0.44 0.05 -89% Windows: git status --ahead-behind 14.30 4.70 -67% git merge-base A B 11.40 1.80 -84% git branch --contains 9.40 1.60 -83% git log --graph -10 24.30 5.30 -78%
- Кроме того, продолжается развитие ранее начатых экспериментальных проектов: уход от применения скомпрометированного алгоритма SHA-1 для хэширования объектов (ожидается опциональная поддержка SHA3–256, которая сможет применяться параллельно с SHA-1) и переход на вторую версию коммуникационного протокола Git (примечателен возможностью фильтрации веток и тегов на стороне сервера и средствами для расширения протокола).
© OpenNet