Привет, %username%, сегодня отличная новость: в открытом доступе появился выпуск распределенной системы управления версиями Git 2.29.0. Наверное, на Хабре не стоит рассказывать, что это такое, ведь Git по-прежнему остается одной из лучших систем.
В новом выпуске сразу 627 изменений, которые внесли 89 разработчиков. О главных изменениях и доработках рассказываем под катом.
- Начнем с экспериментальной возможности использования алгоритма хэширования SHA-256 вместо скомпрометированного SHA-1 при записи объектов в репозиторий. Сейчас хэш формируется на основе содержимого каждого объекта в Git и является его уникальным идентификатором. При любой попытке изменения данных или заголовков объекта выполняется изменение идентификатора. Тем не менее, SHA-1 был скомпрометирован, поэтому Git решено перевести на новый уровень защиты. Изначально планировалось использовать SHA3-256, но в итоге разработчики воспользовались SHA2-256, поскольку SHA2 уже применяется в Git для цифровых подписей. Было принято здравое решение не добавлять новый алгоритм, поскольку если хотя бы один из них скомпрометируют, то это приведет к проблемам с безопасностью. Чем больше элементов в системе, тем выше вероятность, что что-то пойдет не так логика понятна.
- Сейчас в Git добавлена возможность включения нового формата объектов при создании репозитория:
$ git init --object-format=sha256 repo
Initialized empty Git repository in /home/ttaylorr/repo/.git/
$ cd repo
$ echo 'Hello, SHA-256!' >README.md
$ git add README.md
$ git commit -m "README.md: initial commit"
[master (root-commit) 6e92961] README.md: initial commit
1 file changed, 1 insertion(+)
create mode 100644 README.md
$ git rev-parse HEAD
6e929619da9d82c78dd854dfe237c61cbad9e95148c1849b1f96ada5ee800810Выбрать можно лишь между SHA-1 и SHA-256, возможности сочетать разные хеши в одном репозитории нет.
- В командах git fetch и git push появилась поддержка исключающих спецификаций ссылок, которые расширяют правила сопоставления ссылок между ветками в локальном и внешнем репозиториях. Эта возможность окажется полезной в ситуациях, когда необходимо не только выбрать, но и исключить некоторые ветки из сопоставления. Так, когда нужно извлечь все ветки refs/heads/*, кроме одной refs/heads/ref-to-exclude, раньше приходилось указывать полный список с использованием такого скрипта:
$ git ls-remote origin 'refs/heads/*' |
grep -v ref-to-exclude |
awk '{ print $2:$2 }' |
xargs git fetch origin- Сейчас появился оператор исключения "^". Выражения с этим оператором допускают шаблоны, но не могут ссылаться на идентификаторы объекта. Команда с использованием нового оператора может выглядеть следующим образом:
$ git fetch origin 'refs/heads/*:refs/heads/*'
^refs/heads/ref-to-excludeКроме того, в настройках можно использовать исключения:
$ git config --add remote.origin.fetch
^refs/heads/foo- В git shortlog теперь появилась возможность группировки коммитов по содержимому дополнительных полей, Reviewed-by: и Coauthored-by:, а не только по автору или коммитеру. Так что если необходимо вывести список наиболее активно рецензирующих разработчиков, то нужна команда:
$ git shortlog -ns --group=trailer:reviewed-by v2.28.0.. |
head -n5
40 Eric Sunshine
10 Taylor Blau
4 brian m. carlson
2 Elijah Newren
1 Jeff King- Можно указывать несколько выражений "--group" при запуске и использование опции "--format". Так что для учета соавторов или помощников теперь нужно указывать вот что:
$ git shortlog -ns --group=author
--group=trailer:co-authored-by
$ git shortlog --format="...helped %an on %as"
--group=trailer:helped-by v2.28.0..v2.29.0- Если возникает конфликт в процессе выполнения операции git merge, заголовок сообщения о коммите теперь помещается в скобки для явного отделения данных из коммита от диагностических сообщений Git.
- Разработчики вернули отключенную в выпуске 2.27 вторую версию коммуникационного протокола Git. Таким образом, устранена ошибка, которая приводила к проблемам со стабильностью.
- В команду git bisect, которая используется для выявления ревизии, добавлена опция "--first-parent" для изменения отбора коммитов, проходящих между заведомо рабочей ревизией и ревизией, в которой зафиксировано проявление проблемы.
Просмотреть обо всех новшествах можно здесь.
