Прибуття de Git 2.54 Це знаменує собою новий крок в еволюції найпоширенішої у світі системи контролю версій для розробки програмного забезпечення. Спільнота проекту, до якої входить понад 130 осіб, що співпрацюють над цим циклом, зосередилася на спрощенні поширених завдань без шкоди для потужності, що характеризує Git.
Серед нових функцій, які можуть бути найбільш цікавими, є новий спосіб переписати історію Набагато пряміше, це можливість налаштовувати спільні перехоплювачі зі спільних файлів конфігурації та внутрішні вдосконалення, спрямовані на створення швидших та простіших в обслуговуванні репозиторіїв, особливо у великих або корпоративних проектах.
Git 2.54: Огляд нового релізу
Git 2.54 — це проміжна версія на шляху до майбутньої гілки 3.0, але вона приносить зміни, які впливають на щоденну роботу багатьох розробників. По-перше, Випущено експериментальну історію команди gitРозроблено для простих операцій перезапису історії. Крім того, систему перехоплювачів розширено та модернізовано, і тепер нею можна керувати з налаштувань; геометрична стратегія обслуговування тепер використовується за замовчуванням.
Крім того, покращення включені до вже відомих команд, таких як git add -p, git replay, git status або git rebaseа також коригування HTTP-транспорту, способу відображення GPG-сигнатур та внутрішньої роботи бази даних об'єктів. Хоча багато з цих нових функцій є передовими, їхній вплив буде помітним у звичайних робочих процесах у бізнесі, державних адміністраціях та проектах з відкритим кодом з великими репозиторіями.
Нова експериментальна команда git history: просте перезаписування комітів
Одним з основних доповнень у Git 2.54 є історія git, все ще експериментальна команда, призначена для випадків, коли використання інтерактивного перебазування є надмірним. Досі основним інструментом для зміни локальної історії був git rebase -i, дуже гнучкий, але також складніший і схильний залишати користувача в конфліктних станах, які необхідно вирішувати вручну.
з історія git Для конкретних завдань шукається більш прямий підхід: наприклад, виправити друкарську помилку у повідомленні коміту, внесеного кілька змін тому, або розділення коміту, який став занадто великим, на два. Ідея полягає в тому, щоб запропонувати контрольований спосіб налаштування історії без необхідності налаштування всього механізму інтерактивного перебазування зі списками завдань та проміжними кроками.
Підкоманда reword: налаштовує повідомлення комітів без зміни робочого дерева
Перший режим, який запускає нове замовлення, це git history reword <commit>Під час виклику Git відкриває налаштований користувачем редактор з вказане повідомлення фіксаціїщо дозволяє вам змінювати його безпосередньо. Коли ви зберігаєте та закриваєте редактор, Git переписує цей коміт та автоматично оновлює гілки, що спускаються з нього, щоб вказувати на нову версію.
Ключова відмінність від інтерактивного перебазування полягає в тому, що `git history reword` не торкається ні робочого дерева, ні індексуВін лише оновлює історію. Це робить його особливо корисним у середовищах безперервної інтеграції або автоматизованих скриптах, оскільки він може працювати навіть на голих репозиторіях, що поширено на внутрішніх серверах коду компаній або установ, де немає пов'язаного робочого дерева.
підкоманда split: інтерактивне розділення коміту
Другий режим, git history split <commit>Він розроблений для ситуацій, коли один коміт містить зміни, які слід розділити. Під час виконання Git відображає фрагменти, пов'язані з цим комітом, і дозволяє вибрати, які з них слід витягти в новий батьківський коміт, подібно до того, як працює `git extract`. git додати -p під час вирішення питання про те, які фрагменти коду додавати до індексу.
Після вибору фрагментів Git створює Новий коміт з обраними ханками як батьківські для оригіналуВін зберігає невибрані зміни в попередньому коміті. Потім перезаписує гілки-нащадки, щоб вони вказували на нову структуру історії. Знову ж таки, операція виконується без зміни поточного вмісту робочого дерева, що зменшує ймовірність того, що репозиторій залишиться у складному проміжному стані.
Обмеження та сумісність з іншими робочими процесами
Щоб контролювати поведінку, Історія git не підтримує історії з коммітами злиття і відмовляється продовжувати операцію, якщо в результаті виникають конфлікти злиття. Він призначений для незначних налаштувань, а не для масових перезаписів, як ті, що зазвичай використовуються за допомогою git rebase -i або більш агресивні стратегії очищення історії.
Внутрішньо командування спирається на механізм git-відтворенняякий консолідувався як експериментальний інструмент для відтворення комітів на іншій базі без торкання робочого дерева. Частина цієї роботи полягала у вилученні цієї логіки у спільну бібліотеку, щоб обидва git history оскільки інші майбутні функціональні можливості можуть отримати вигоду від більш модульної інфраструктури, яку легше автоматизувати за допомогою скриптів або сторонніх інструментів.
Хуки на основі конфігурації: спільне використання та поєднання автоматизацій
Ще однією помітною новою функцією Git 2.54 є можливість визначати гачки безпосередньо у файлах конфігурації, замість того, щоб покладатися виключно на скрипти, розміщені в каталозі .git/hooks або за маршрутом, зазначеним core.hooksPathЦя зміна значно спрощує обмін перевірками між різними репозиторіями без необхідності реплікації файлів вручну.
Досі, щоб застосувати, наприклад, форматувальник коду або аналізатор секретів перед кожним комітом у кількох проектах, потрібно було копіювати скрипт перехоплення до кожного репозиторію або використовувати зовнішні інструменти керування перехопленнями. Завдяки новому підходу можна визначити центральні гачки в ~/.gitconfig або в а /etc/gitconfig корпоративними, і що вони застосовуються там, де це необхідно.
Визначення хуків за конфігурацією та кількома командами на подію
Новий синтаксис базується на ключах конфігурації стилю hook.<nombre>.command y hook.<nombre>.eventПерший вказує, яка команда буде виконана, а другий визначає яка подія-перехоплювач її запускаєнаприклад, а pre-commit O ООН pre-pushОскільки це стандартна конфігурація, ці налаштування можуть співіснувати на різних рівнях: користувацькому, системному або репозиторному.
Крім того, Git тепер дозволяє це кілька гачків призначено одній подіїІншими словами, ви можете визначити, наприклад, лінтер та сканер облікових даних для запуску на кожному з них. pre-commitбез необхідності вручну об'єднувати їх в один скрипт. Git перебирає записи конфігурації по порядку та виконує кожну команду, зберігаючи при цьому підтримку класичного скрипта. $GIT_DIR/hooks, який продовжує виконуватися в кінці, щоб не порушувати попередні конфігурації.
Управління, деактивація та внутрішня модернізація гачків
Щоб перевірити, які хуки активні та звідки вони походять, включено наступну команду git hook listщо показує походження кожного з них, що корисно під час управління централізовані конфігурації У корпоративному середовищі, якщо певному репозиторію потрібно виключити перехоплювач, успадкований від глобального файлу, достатньо встановити hook.<nombre>.enabled = false, без необхідності видалення або зміни початкової конфігурації.
Під капотом Git має уніфіковано та модернізовано спосіб обробки багатьох внутрішніх гачківКілька точок інтеграції, якими раніше керували за допомогою спеціальних маршрутів, таких як перехоплювачі для pre-push, post-rewrite або тих receive-packТепер вони використовують новий API hooks. Це не лише забезпечує узгодженість, але й спрощує адаптацію середовищ безперервної інтеграції або платформ для створення коду до майбутніх змін без необхідності переписувати окремі інтеграції.
Геометричне обслуговування як стратегія за замовчуванням
У попередніх версіях Git запровадив так звану стратегію геометричні в git maintenanceРозроблена для зменшення витрат на перепакування у великих репозиторіях, ця стратегія аналізує існуючі пакетні файли та шукає комбінації, що утворюють геометричну прогресію за кількістю об'єктів, конденсуючи їхній вміст без необхідності щоразу виконувати повну збірку сміття.
З Git 2.54 цей підхід стає параметр за замовчуванням для ручного обслуговуванняКоли воно працює git maintenance run Без уточнення стратегії автоматично обирається геометричний підхід, замість того, щоб вдаватися безпосередньо до класичного завдання gc який намагається згрупувати все в один пакет.
На практиці це означає, що Репозиторії обслуговуються ефективніше З самого початку це особливо цікаво для проектів з довгою історією або для організацій, які керують великими монорепозиторіями. Геометрична стратегія поєднує інкрементальні пакети, коли це має сенс, і вдається до лише gc Завершити, коли фактично все буде об'єднано в один пакетний файл. Під час процесу граф комітів, рефлоги та інші допоміжні структури постійно оновлюються.
Ті, хто вже налаштував maintenance.strategy = geometric Вони не помітять жодних змін, оскільки це бажання поважається. А ті, хто віддає перевагу традиційному підходу, можуть нав'язати стратегію gc налаштування maintenance.strategy = gcтаким чином зберігаючи сумісність з більш консервативними потоками.
Покращення інтерактивних та експериментальних команд
Окрім основних нових функцій, Git 2.54 пропонує цілий ряд змін, спрямованих на... покращити щоденний користувацький досвідособливо в командах, які використовуються інтерактивно для керування змінами.
Удосконалення в git: додавання -py нових опцій навігації
Інтерактивний режим git add -p та пов’язані команди отримують різні покращення зручності використання. Під час навігації між частинами за допомогою клавіш J y KGit тепер показує, чи фрагмент було прийнято або пропущено ранішеуникаючи необхідності вручну запам'ятовувати кожне рішення.
Також додано опцію --no-auto-advanceщо змінює поведінку після завершення роботи з частинами файлу. Замість автоматичного переходу до наступного файлу, сеанс залишається на поточному, що дозволяє використовувати < y > для спокійнішого переміщення між файлами. Такий спосіб роботи корисний, коли ви хочете переглянути вибрані зміни в цілому, перш ніж підтвердити їх.
git replay: більше можливостей для повторного виконання комітів
Експериментальний порядок git-відтворенняФункція, призначена для реплікації комітів на новій базі без зміни робочого дерева, продовжує набувати можливостей. У цій версії вона тепер виконує атомарно оновлювати посилання За замовчуванням, замість виведення команд update-ref на стандартний вихід.
Крім того, він включає режим --revert дозволяє скасувати зміни з низки комітівВін здатний відкидати коміти, які стають порожніми під час процесу, а також тепер підтримує відтворення історії до кореневого коміту. Ці покращення добре поєднуються з використанням git history, який спирається на ту саму інфраструктуру для забезпечення безпечнішого досвіду.
Нова опція – трейлер у git rebase
Ще одним цікавим коригуванням є додавання --trailer en git rebaseякий використовує логіку interpret-trailers пункт додати той самий трейлер до кожного коміту overshotЗамість того, щоб створювати довгі команди за допомогою -x і дзвінки до git commit --amend --no-edit --trailer=...Ви можете безпосередньо вказати потрібний трейлер під час запуску перевищення.
Це значно спрощує повторювані завдання, такі як додавання рядків тексту Reviewed-by: або анотації, подібні до серії комітів, що є поширеним явищем у формальних процесах перевірки коду, що використовуються в розподілених командах.
HTTP-транспорт та керування підписами: більш вдосконалена поведінка
Що стосується мережевого зв'язку, Git 2.54 вносить відповідні зміни в обробку HTTP-відповідей та інтерпретацію криптографічних підписів, пов'язаних з коммітами та тегами.
Керування відповідями HTTP 429 та налаштовувані повторні спроби
HTTP-транспорт Git вчиться правильно інтерпретувати коди 429 «Занадто багато запитів»Досі, коли сервер повертав помилку 429, це вважалося фатальною помилкою, і операція завершувалася невдало. Починаючи з цієї версії, Git може повторити запит, враховуючи значення заголовка. Retry-After якщо є, або використовуючи налаштовану затримку за допомогою нової опції http.retryAfter.
Також додаються коригування http.maxRetries y http.maxRetryTime, які дозволяють контролювати максимальну кількість повторних спроб та загальний час, витрачений на нихЦе практично в корпоративному середовищі, де потрібен доступ до перевантажених серверів або серверів зі суворими політиками обмеження запитів, що допомагає оптимізувати операції. fetch y push бути більш стійким, не караючи сервер.
Обробка GPG-підписів із застарілими ключами
Щодо безпеки, виправлено потенційно оманливу поведінку: коли коміт підписувався ключем GPG, термін дії якого згодом закінчився, Git відображав підпис у тривожний червоний колірЦе свідчило про те, що підпис був недійсним. Однак, якщо підпис був дійсним на той момент, його дійсність має залишатися, навіть якщо термін дії ключа з того часу минув.
Git 2.54 коригує цю логіку та продовжує розглядати Підписи, які були правильно зроблені до закінчення терміну дії ключа, є дійсними.Це дозволяє уникнути непотрібних сповіщень. Це забезпечує точнішу картину історії репозиторію, що актуально для проектів з тривалим життєвим циклом, таких як інституційне або державне адміністративне програмне забезпечення, яке підтримується протягом багатьох років.
Нові можливості перевірки та налаштування історії
Кілька команд, призначених для дослідження історії, отримали покращення, що підвищують їхню гнучкість і дозволяють отримувати більш адаптовані результати для кожного випадку.
`git log -L` інтегрується зі стандартним механізмом різниці
Вибір git log -LФункцію, яка дозволяє відстежувати еволюцію діапазону рядків у певному файлі, було перереалізовано для маршрутизації її виводу через стандартний механізм порівняння GitРаніше він використовував власний шлях, що робило його несумісним з дуже корисними опціями, такими як -S y -G (так звані «кирки») або з різними форматами нашивок.
Зі зміною, внесеною у Git 2.54, -L стає сумісним з розширений пошук контенту та різних форматівв тому числі --word-diff o --color-movedТаким чином, вивід можна обмежити певною функцією та водночас фільтрувати лише для комітів, які додають або видаляють певний символ, що полегшує аудит коду та регресійний аналіз.
git blame з вибором алгоритму diff
Команда звинувачувати git, використовується для перегляду того, який коміт ввів кожен рядок файлу, вивчає новий параметр --diff-algorithmЦе дозволяє вибирати між різними алгоритмами різниці, такими як гістограма, терпіння або мінімальний, під час розрахунку атрибуції ліній.
Залежно від типу змін, яких зазнав файл, Вибір одного алгоритму замість іншого може дати чіткіші результатиЦе зменшує шум у високоактивних історіях. У середовищах, де детальні огляди високо цінуються, такий рівень контролю може мати вирішальне значення під час розслідування того, хто впровадив певний блок коду.
Оптимізація сховища та об'єктні бази даних
Зміни в цій версії не обмежуються інтерфейсом користувача; також було проведено значну роботу над тим, як працює Git. організовує та отримує доступ до даних внутрішньоЦе має особливо значний вплив на великі сховища.
Інкрементальні багатопакетні індекси та ущільнення
Дзвінки багатопакетні інкрементальні індекси (MIDX)Функції, які вже були покращені в попередніх версіях, Git 2.54 тепер включає підтримку стиснення шарів. Цей механізм поєднує менші шари MIDX разом з пов'язаними з ними растровими зображеннями досяжності, щоб зберегти ланцюжок шарів розумного розміру.
Цей крок важливий для практичне використання інкрементального MIDX у довготривалих репозиторіяхнаприклад, у великих організаціях або громадських проектах з багаторічною історією. Ущільнення шарів зменшує складність пошуку та покращує продуктивність таких операцій, як fetch, clone часткові або історичні перевірки.
Реструктуризація об'єктної бази даних (ODB)
Внутрішньо, a глибокий рефакторинг API об'єктної бази даних (ODB). Тепер використовується підключаємий дизайн бекенду, в якому такі функції, як read_object(), write_object() o for_each_object() Вони відправляються за допомогою вказівників функцій за походженням.
Хоча ця зміна не одразу помітна для кінцевого користувача, вона закладає основу для майбутні альтернативні серверні системи зберігання даних або більш гнучкі конфігурації об'єктної бази даних. Для компаній зі специфічними вимогами до дотримання нормативних вимог або інтеграцією з власними системами зберігання даних ця модульність може відкрити шлях до більш індивідуальних рішень.
Покращення статусу, псевдонімів, заповнення та інших деталей
Git 2.54 також включає низку змін, які, хоч і менш масштабні, сприяють удосконаленню щоденного використання та адаптації Git до різних лінгвістичних та мережевих контекстів.
статус git та порівняння з кількома віддаленими гілками
Команда Git статус дебютує з опцією конфігурації status.compareBranchesЗа замовчуванням ця команда показувала, як поточна гілка порівнюється з її налаштованою розгорнутою гілкою, щось типове на кшталт origin/mainЗавдяки новій опції ви можете запросити порівняння з гілкою push або з обома одночасно.
Ця функціональність розроблена для того, щоб трикутні потоки, поширене явище під час роботи з форками: ви можете завантажувати з офіційного віддаленого сервера та надсилати зміни на інший, завжди чітко визначаючи, скільки комітів розділяє кожну гілку, що зменшує несподіванки під час синхронізації репозиторіїв.
Псевдонім з міжнародними символами
Досі псевдоніми Git обмежувалися буквено-цифровими символами ASCII та дефісами, що запобігало використанню імен іншими мовами з акцентами або різними алфавітами. Новий синтаксис підтримує практично будь-які символи, крім розривів рядків та NUL. Зіставлення виконується у вигляді необроблених байтів та враховує регістр. Крім того, систему автозаповнення оболонки було оновлено для обробки цих псевдонімів, що спрощує використання Git у багатомовних командах.
Заповнення Git практичніше у часткових клонах
Експериментальна команда git-заповненняКоманда, яка використовується для завантаження відсутніх блобів у часткових клонах, також покращується. Раніше команда завжди отримувала доступні блоби з HEAD по всьому дереву, що може бути надмірним у особливо великих репозиторіях.
Git 2.54 додає підтримку для перегляньте аргументи та специфікацію шляхущоб заповнення можна було обмежити певним діапазоном історії (наприклад, main~100..main) або до певних конкретних маршрутів (git backfill -- '*.c'), включаючи шаблони підстановочних символів. Це значно спрощує роботу з великими частковими клонами, де потрібно завершити історію лише певної частини коду.
Інші налаштування та детальні покращення
Список змін Git 2.54 містить довгий список невеликих покращень. Серед них виправлення алгоритму diff. гістограмащо тепер запобігає переміщенню груп змін під час фази ущільнення таким чином, що це порушує вибрані опорні лінії, створюючи чистіші та менш надлишкові різниці.
Такі інструменти, як git config list , який стає офіційним способом переліку конфігурації, git merge-file яка потім враховує доступну конфігурацію навіть поза репозиторієм, та кілька пов'язаних утиліт git send-emailякі отримують підтримку клієнтських сертифікатів та ретельніше обробляють вибрані користувачем набори символів.
Еволюція Git продовжується хорошими темпами з версією 2.54, яка поєднує видимі покращення для користувача, як новий порядок git history або налаштовувані перехоплювачі, які вимагають значної роботи над внутрішньою інфраструктурою системи. Все це вказує на більш надійну, гнучку екосистему, краще підготовлену до викликів дедалі більших репозиторіїв та більш різноманітних команд.
