випуск розподіленої системи керування вихідними текстами . Git є однією з найпопулярніших, надійних та високопродуктивних систем управління версіями, що надає гнучкі засоби нелінійної розробки, що базуються на відгалуженні та злитті гілок. Для забезпечення цілісності історії та стійкості до змін заднім числом використовуються неявне хешування всієї попередньої історії в кожному коміті, також можливе посвідчення цифровими підписами розробників окремих тегів та коммітів.
Порівняно з минулим випуском у нову версію прийнято 504 зміни, підготовлені за участю 64 розробників, з яких 12 вперше взяли участь у розробці. :
- Здійснено перехід за замовчуванням на комунікаційного протоколу Git, який використовується при віддаленому підключенні клієнта до Git-сервера. Друга версія протоколу примітна наданням можливості фільтрації гілок та тегів на стороні сервера з віддачею клієнту скороченого списку посилань. Раніше під час виконання будь-якої команди вилучення клієнту завжди надсилався повний список посилань у всьому репозиторії, навіть коли клієнт оновлював лише одну гілку чи перевіряв актуальність своєї копії репозиторію. Іншим помітним нововведенням є можливість додавання до протоколу нових можливостей у міру появи в інструментарії нової функціональності. Код клієнта залишається сумісним зі старим протоколом і може продовжувати працювати як з новими, так і старими серверами, автоматично відкочуючись на першу версію, якщо сервер не підтримує другу.
- До команди «git config» додано опцію «—show-scope», що спрощує виявлення місця, в якому визначені ті чи інші налаштування. Git дозволяє визначати налаштування в різних місцях: у репозиторії (.git/info/config), у каталозі користувача (~/.gitconfig), у загальносистемному файлі конфігурації (/etc/gitconfig), а також через опції командного рядка та змінні оточення. При виконанні «git config» досить важко зрозуміти, де саме визначено шукане налаштування. Для вирішення цього завдання була доступна опція «-show-origin», але вона лише показує шлях до файлу, в якому визначено налаштування, що корисно при намірі відредагувати файл, але не допомагає, якщо потрібно змінити значення через «git config» за допомогою опцій "-system", "-global" або "-local". Нова опція "-show-scope" відображає контекст визначення змінних і може застосовуватися спільно з "show-origin":
$ git-list-show-scope-show-origin
Global file:/home/user/.gitconfig diff.interhunkcontext=1
global file:/home/user/.gitconfig push.default=current
[…] local file:.git/config branch.master.remote=origin
local file:.git/config branch.master.merge=refs/heads/master$ git config -show-scope -get-regexp 'diff.*'
global diff.statgraphwidth 35
local diff.colormoved plain$ git config -global -unset diff.statgraphwidth
- У налаштуваннях прив'язки дозволено використання масок в URL. Будь-які налаштування HTTP та облікові дані в Git можуть бути встановлені як для всіх з'єднань (http.extraHeader, credential.helper), так і для з'єднань у прив'язці до URL (credential.https://example.com.helper, credential.https: //example.com.helper). До цього часу використання масок, таких як *.example.com, допускалося лише для налаштувань HTTP, але не підтримувалося для прив'язування облікових даних. У Git 2.26 ці відмінності усунуті і, наприклад, для прив'язки імені користувача до всіх піддоменів тепер можна вказати:
[credential "https://*.example.com"]
username = ttaylorr
- Продовжено розширення експериментальної підтримки часткового клонування (partial clones), що дозволяє переносити лише частину даних та працювати з неповною копією репозиторію. У новому випуску додано нову команду «git sparse-checkout add», яка дозволяє додавати окремі директорії для застосування операції «checkout» лише до частини робочого дерева, замість перерахування всіх подібних директорій разом через команду «git sparse-checkout set» (можна додавати по однієї директорії, без повторного завдання всього списку щоразу).
Наприклад, для клонування репозиторію git/git без передачі блобів, обмеження перевірки лише кореневим каталогом робочої копії та роздільною позначкою для вилучення каталогів «t» та «Documentation» можна вказати:$ git clone-filter=blob:none-sparse [захищено електронною поштою]:git/git.git
$ cd git
$ git sparse-checkout init-cone$ git sparse-checkout add t
....
$ git sparse-checkout add Documentation
....
$ git sparse-checkout list
документація
t - Помітно збільшено продуктивність команди «git grep», яка використовується для пошуку як в актуальному вмісті репозиторію, так і в історичних ревізіях. Для прискорення пошуку допускалося сканування вмісту робочого дерева з допомогою кількох потоків («git grep —threads»), але пошук у історичних ревізіях був однопоточним. Тепер це обмеження знято рахунок реалізації можливості розпаралелювання операцій читання зі сховища об'єктів. За замовчуванням кількість потоків встановлюється рівним числу ядер CPU, що в більшості випадків тепер не потребує явного виставлення опції «threads».
- Додано підтримку автодоповнення введення субкоманд, шляхів, посилань та інших аргументів команди «git worktree», що дозволяє працювати з кількома робочими копіями репозиторію.
- Додано підтримку яскравих кольорів, для яких є ANSI escape-послідовності. Наприклад, у налаштуваннях кольорів підсвічування «git config —color» або «git diff —color-moved» через опцію «format» для яскраво-блакитного можна вказувати %C(brightblue).
- Додана нова версія скрипту , що забезпечує інтеграцію з механізмом для прискорення відстеження зміни файлів та появи нових файлів. Після оновлення git потрібно hook в репозиторії.
- Додані оптимізації для прискорення операцій часткового клонування (partial clones), пов'язані із застосуванням бітових карток
(bitmap machinery) для запобігання повному перебору всіх об'єктів під час фільтрації віддачі. Перевірка на блоби (-filter=blob:none і -filter=blob:limit=n) при частковому клонуванні тепер проводиться
значно швидше. GitHub оголосив про застосування патчів з даними оптимізаціями та експериментальної підтримки часткового клонування. - Команда «git rebase» переведена на інший бекенд, який використовує за умовчанням механізм merge (раніше використовувався для rebase -i) замість 'patch+apply'. У деяких дрібницях бекенди відрізняються, наприклад, після продовження операції після усунення конфлікту (git rebase -continue) новий бекенд пропонує відредагувати повідомлення комміту, а старий просто використовував старе повідомлення. Для повернення старої поведінки можна використовувати опцію «-apply» або встановити змінну конфігурації 'rebase.backend' у значення 'apply'.
- Приклад обробника параметрів аутентифікації, заданих через .netrc, приведений до вигляду, придатного для використання коробки.
- Додано налаштування gpg.minTrustLevel для визначення мінімального рівня довіри для різних елементів, які перевіряють цифровий підпис.
- У git rm і git stash додана опція pathspec-from-file.
- Продовжено вдосконалення тестових наборів у рамках підготовки до переходу на алгоритм хешування SHA-2 замість SHA-1.
Джерело: opennet.ru