Пристигането 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, много гъвкав, но също така по-сложен и склонен да оставя потребителя в конфликтни състояния, които трябва да бъдат разрешени ръчно.
Con история на git За специфични задачи се търси по-директен подход: например, коригиране на печатна грешка в съобщението на commit отпреди няколко промени или разделяне на commit, който е станал твърде голям, на две. Идеята е да се предложи контролиран начин за настройване на историята, без да се налага настройване на целия механизъм на интерактивно презареждане със списъци със задачи и междинни стъпки.
Подкоманда за преформулиране: променя съобщенията за коммит, без да се докосва работното дърво
Първият режим, който новата поръчка стартира, е git history reword <commit>Когато бъде извикан, Git отваря конфигурирания от потребителя редактор с посочено съобщение за commitкоето ви позволява да го променяте директно. Когато запазите и затворите редактора, Git пренаписва този commit и автоматично актуализира клоновете, които водят от него, за да сочат към новата версия.
Ключовата разлика в сравнение с интерактивното пребазиране е, че `git history reword` не докосва нито работното дърво, нито индексаТой само актуализира историята. Това го прави особено полезен в среди за непрекъсната интеграция или автоматизирани скриптове, тъй като може да работи дори върху голи хранилища, което е често срещано във вътрешни кодови сървъри на компании или институции, където няма свързано работно дърво.
подкоманда split: интерактивно разделяне на commit
Вторият режим, git history split <commit>Проектиран е за ситуации, в които един commit съдържа промени, които трябва да бъдат разделени. Когато се изпълни, Git показва частите, свързани с този commit, и ви позволява да изберете кои от тях да бъдат извлечени в нов родителски commit, подобно на начина, по който работи `git extract`. git добавете -p когато решавате кои части от код да добавите към индекса.
След като фрагментите са избрани, Git създава Нов commit с избраните хънкове като родител на оригиналаЗапазва неизбраните промени в предишния commit. След това пренаписва наследствените клонове, за да сочат към новата структура на историята. Отново операцията се изпълнява без да се променя текущото съдържание на работното дърво, което намалява вероятността хранилището да остане в сложно междинно състояние.
Ограничения и съвместимост с други работни процеси
За да се поддържа контролируемо поведение, git history не поддържа истории със сливания (merge commits) и отказва да продължи, ако операцията доведе до конфликти при сливане. Той е предназначен за малки корекции, а не за масивни пренаписвания, каквито обикновено се извършват с git rebase -i или по-агресивни стратегии за почистване на историята.
Вътрешно командването разчита на механизма на git повторениекойто се консолидира като експериментален инструмент за възпроизвеждане на коммити на друга база, без да се докосва работното дърво. Част от тази работа се състои в извличане на тази логика в обща библиотека, така че и двете git history тъй като други бъдещи функционалности могат да се възползват от по-модулна инфраструктура, която е по-лесна за автоматизиране от скриптове или инструменти на трети страни.
Куки, базирани на конфигурация: споделяне и комбиниране на автоматизации
Друга забележителна нова функция на Git 2.54 е възможността да дефинирайте кукичките директно в конфигурационните файлове, вместо да се разчита единствено на скриптове, поставени в директорията .git/hooks или по маршрута, посочен от core.hooksPathТази промяна значително улеснява споделянето на проверки между различни хранилища, без да се налага ръчно репликиране на файлове.
Досега, за да се приложи например формататор на код или анализатор на секрети преди всяко попълване в множество проекти, беше необходимо да се копира скриптът за закачане във всяко хранилище или да се използват външни инструменти за управление на закачалки. С новия подход е възможно да се дефинират централни куки в ~/.gitconfig или в a /etc/gitconfig корпоративни и че те се прилагат, където е необходимо.
Дефиниране на кукички чрез конфигурация и множество команди на събитие
Новият синтаксис е базиран на ключове за конфигуриране на стилове hook.<nombre>.command y hook.<nombre>.eventПървият показва коя команда ще бъде изпълнена, а вторият уточнява кое събитие за закачане го задействанапример pre-commit или pre-pushТъй като това е стандартна конфигурация, тези настройки могат да съществуват едновременно на различни нива: потребителско, системно или хранилищно.
Освен това, Git вече позволява това множество куки са присвоени на едно и също събитиеС други думи, можете да дефинирате например линтер и скенер за удостоверения, които да се изпълняват на всеки от тях. pre-commitбез да е необходимо ръчно да ги комбинирате в един скрипт. Git итерира през конфигурационните записи по ред и изпълнява всяка команда, като същевременно поддържа поддръжката за класическия скрипт. $GIT_DIR/hooks, който продължава да се изпълнява в края, за да не се нарушат предишните конфигурации.
Управление, деактивиране и вътрешна модернизация на куките
За да се провери кои куки са активни и откъде идват, е включена следната команда git hook listкоето показва произхода на всеки един, нещо полезно при управлението централизирани конфигурации В корпоративни среди, ако дадено хранилище трябва да изключи hook, наследен от глобален файл, е достатъчно да се зададе hook.<nombre>.enabled = false, без да е необходимо да изтривате или променяте оригиналната конфигурация.
Под капака, Git има унифициран и модернизиран начин, по който обработва много от вътрешните си кукиНяколко точки на интеграция, които преди това са били управлявани с ad hoc маршрути, като например куки за pre-push, post-rewrite или тези на receive-packСега те използват новия hooks API. Това не само осигурява последователност, но и улеснява адаптирането на среди за непрекъсната интеграция или платформи за създаване на код към бъдещи промени, без да се налага пренаписване на специфични интеграции.
Геометричното поддържане като стратегия по подразбиране
В предишни версии 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: повече зрялост за повторно изпълнение на commit-ове
Експерименталният ред git повторениеФункцията, предназначена да репликира коммити на нова база без промяна на работното дърво, продължава да набира възможности. В тази версия тя вече изпълнява атомарно актуализиране на препратки По подразбиране, вместо да се изписват команди update-ref на стандартен изход.
Освен това, той включва режим --revert позволява отмяна на промените от набор от коммитиТой е способен да отхвърля commit-и, които се изпразват по време на процеса, и вече поддържа преиграване на историята обратно до коренния commit. Тези подобрения се вписват добре в използването на git history, който разчита на същата инфраструктура, за да предложи по-безопасно изживяване.
Нова опция – трейлър в git rebase
Друга интересна корекция е добавянето на --trailer en git пребазиранекоето се възползва от логиката на interpret-trailers за добавете един и същ трейлър към всеки overshot commitВместо да се изграждат дълги команди с -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 подписи с изтекли ключове
По отношение на сигурността е коригирано потенциално подвеждащо поведение: когато commit е бил подписан с GPG ключ, чийто срок на валидност впоследствие е изтекъл, Git е показвал подписа в тревожен червен цвятТова предполага, че подписът е невалиден. Ако обаче подписът е бил валиден по това време, тази валидност би трябвало да остане, дори ако ключът е изтекъл оттогава.
Git 2.54 коригира тази логика и продължава с разглеждането на Подписите, които са направени правилно преди изтичането на срока на ключа, са валидни.Това избягва ненужни предупреждения. Предоставя по-точна картина на историята на хранилището, което е от значение за проекти с дълъг жизнен цикъл, като например институционален или публичен административен софтуер, който се поддържа в продължение на много години.
Нови възможности за проверка и персонализиране на историята
Няколко команди, предназначени за изследване на историята, получават подобрения, които увеличават тяхната гъвкавост и позволяват по-персонализирани резултати за всеки отделен случай.
`git log -L` се интегрира със стандартните машини за сравнение (diff).
Опцията git log -LФункцията, която позволява проследяване на еволюцията на диапазон от редове в конкретен файл, е преимплементирана, за да насочва изхода си през стандартен механизъм за сравнение на GitПреди това използваше собствен път, което го правеше несъвместим с много полезни опции като -S y -G (т. нар. „кирки“) или с различни формати на кръпки.
С промяната, въведена в Git 2.54, -L става съвместим с разширено търсене на съдържание и различни формативключително --word-diff o --color-movedПо този начин изходът може да бъде ограничен до конкретна функция и същевременно да бъде филтриран само за коммити, които добавят или премахват специфичен символ, което улеснява одитите на кода и регресионния анализ.
git blame с избор на diff алгоритъм
Командата обвинявам git, използва се, за да се види кой commit е въвел всеки ред от файл, научава нова опция --diff-algorithmТова ви позволява да избирате между различни алгоритми за разлика, като например хистограма, търпение или минимално, когато изчислявате атрибуцията на линиите.
В зависимост от вида на промените, които е претърпял файлът, Изборът на един алгоритъм пред друг може да предложи по-ясни резултатиТова намалява шума в силно активните истории на кода. В среди, където подробните прегледи са високо ценени, това ниво на контрол може да е от решаващо значение при разследване на това кой е въвел определен блок код.
Оптимизация на съхранението и обектни бази данни
Промените в тази версия не се ограничават само до потребителския интерфейс; има и значителна работа по начина, по който работи Git. организира и осъществява достъп до данни вътрешноТова има особено значително въздействие върху големите хранилища.
Инкрементални индекси за многопакетни структури и уплътняване
Обажданията многопакетни инкрементални индекси (MIDX)Функциите, които вече бяха подобрени в предишни версии, Git 2.54 вече включва поддръжка за уплътняване на слоеве. Този механизъм комбинира по-малки MIDX слоеве, заедно със свързаните с тях растерни изображения за достигаемост, за да поддържа веригата от слоеве с разумен размер.
Тази стъпка е важна за Практическо използване на инкрементален MIDX в дълготрайни хранилищакато например тези на големи организации или обществени проекти с дългогодишна история. Компактирането на слоевете намалява сложността на търсенията и подобрява производителността при операции като fetch, clone частични или исторически проверки.
Преструктуриране на обектна база данни (ODB)
Вътрешно, a дълбоко рефакториране на API на обектната база данни (ODB). Сега се използва дизайн с възможност за добавяне на backend, в който функции като read_object(), write_object() o for_each_object() Те се изпращат с помощта на функционални указатели по произход.
Въпреки че тази промяна не е веднага видима за крайния потребител, тя полага основите за бъдещи алтернативни бекендове за съхранение или по-гъвкави конфигурации на обектни бази данни. За компании със специфични изисквания за съответствие с регулаторните изисквания или интеграция със собствени системи за съхранение, тази модулност може да отвори вратата към по-персонализирани решения.
Подобрения в състоянието, псевдонимите, запълването и други подробности
Git 2.54 включва и редица корекции, които, макар и по-малки, допринасят за усъвършенстване на ежедневната употреба и адаптиране на Git към различни езикови и мрежови контексти.
git статус и сравнение с няколко отдалечени клона
Командата git статус дебютира опцията за конфигурация status.compareBranchesПо подразбиране тази команда показваше как текущият клон се сравнява с конфигурирания му upstream, нещо типично като origin/mainС новата опция можете да заявите сравнение с push клона или и с двата едновременно.
Тази функционалност е предназначена да триъгълни потоци, често срещано при работа с forks: можете да изтегляте от официално дистанционно управление и да изпращате промени към друго, като през цялото време е ясно колко коммита разделят всеки клон, което намалява изненадите при синхронизиране на хранилища.
Псевдоним с международни символи
Досега псевдонимите на Git бяха ограничени до ASCII буквено-цифрови символи и тирета, което предотвратяваше използването на имена на други езици с ударения или различни азбуки. Новият синтаксис поддържа почти всеки символ, с изключение на прекъсвания на реда и NUL. Съвпадението се извършва като сурови байтове и е чувствително към главни и малки букви. Освен това, системата за автоматично довършване на shell е актуализирана, за да обработва тези псевдоними, което прави Git по-лесен за използване в многоезични екипи.
Git backfill е по-практичен при частични клонинги
Експерименталната команда 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 или конфигурируеми куки, които изискват значителна работа върху вътрешната инфраструктура на системата. Всичко това сочи към по-стабилна и гъвкава екосистема, по-добре подготвена за предизвикателствата на все по-големите хранилища и по-разнообразните екипи.
