Příjezd de Git 2.54 Toto představuje nový krok ve vývoji nejpoužívanějšího systému pro správu verzí softwaru na světě. Projektová komunita s více než 130 lidmi spolupracujícími na tomto cyklu se zaměřila na zjednodušení běžných úkolů, aniž by obětovala výkon, který charakterizuje Git.
Mezi nové funkce, které by mohly být nejzajímavější, patří nový způsob přepsat historii Mnohem přímočařejším způsobem je možnost konfigurovat sdílené hooky ze společných konfiguračních souborů a interní vylepšení, která usilují o rychlejší a snadněji udržovatelné repozitáře, zejména ve velkých nebo korporátních projektech.
Git 2.54: Přehled nové verze
Git 2.54 je přechodná verze na cestě k budoucí větvi 3.0, ale přináší změny, které ovlivňují každodenní práci mnoha vývojářů. V první řadě, Experimentální příkaz git history je zveřejněnNavrženo pro jednoduché operace přepisování historie. Systém zavěšení byl dále rozšířen a modernizován a nyní jej lze spravovat z nastavení; strategie geometrické údržby je nyní výchozí.
Kromě toho jsou vylepšení zahrnuta i v již známých příkazech, jako například git add -p, git replay, git status nebo git rebasestejně jako úpravy HTTP transportu, způsobu zobrazování GPG podpisů a interního fungování objektové databáze. Ačkoli je mnoho z těchto nových funkcí pokročilých, jejich dopad bude patrný v běžných pracovních postupech v podnicích, veřejné správě a open source projektech s velkými repozitáři.
Nová experimentální historie příkazů v gitu: snadné přepisování commitů
Jedním z hlavních doplňků v Gitu 2.54 je historie gitu, stále experimentální příkaz určený k pokrytí případů, kdy je použití interaktivního rebase zbytečné. Doposud byl pro úpravu lokální historie nejpoužívanějším nástrojem git rebase -i, velmi flexibilní, ale také složitější a náchylnější k tomu, že uživatele nechává v konfliktních stavech, které je nutné řešit ručně.
s historie gitu Pro specifické úkoly se hledá přímější přístup: například opravit překlep ve zprávě commitu z doby před několika změnami nebo rozdělením commitu, který se stal příliš velkým, na dva. Cílem je nabídnout kontrolovaný způsob úpravy historie, aniž by bylo nutné nastavovat celý mechanismus interaktivního rebase se seznamy úkolů a mezikroky.
Dílčí příkaz reword: úprava zpráv commitu bez zásahu do pracovního stromu
Prvním režimem, který nová objednávka spouští, je git history reword <commit>Po spuštění Git otevře uživatelsky nakonfigurovaný editor s zadaná zpráva o potvrzenícož vám umožňuje jej přímo upravovat. Když uložíte a zavřete editor, Git přepíše daný commit a automaticky aktualizuje větve, které z něj sestupují, tak, aby ukazovaly na novou verzi.
Klíčový rozdíl oproti interaktivnímu rebase je ten, že Funkce `git history reword` se nedotýká ani pracovního stromu, ani indexu.Aktualizuje pouze historii. Díky tomu je obzvláště užitečný v prostředích s kontinuální integrací nebo automatizovaných skriptech, protože může fungovat i na holých repozitářích, což je běžné u interních kódových serverů firem nebo institucí, kde neexistuje žádný přidružený pracovní strom.
Dílčí příkaz split: interaktivní rozdělení commitu
Druhý režim, git history split <commit>Je navržen pro situace, kdy jeden commit obsahuje změny, které by měly být odděleny. Po spuštění Git zobrazí bloky (hunky) spojené s daným commitem a umožní vám vybrat, které z nich by měly být extrahovány do nového nadřazeného commitu, podobně jako funguje `git extract`. git přidat -p při rozhodování, které části kódu přidat do indexu.
Jakmile jsou fragmenty vybrány, Git vytvoří Nový commit s vybranými chunky jako rodičem origináluNevybrané změny se uchovávají v předchozím commitu. Poté se přepíší následné větve tak, aby odkazovaly na novou strukturu historie. Operace opět probíhá beze změny aktuálního obsahu pracovního stromu, což snižuje pravděpodobnost, že repozitář zůstane v komplikovaném mezilehlém stavu.
Omezení a kompatibilita s jinými pracovními postupy
Aby bylo chování ovladatelné, Historie v Gitu nepodporuje historii se sloučenými commity. a odmítá pokračovat, pokud operace vede ke konfliktům sloučení. Je určen pro drobné úpravy, nikoli pro rozsáhlé přepisy, jaké se obvykle řeší pomocí git rebase -i nebo agresivnější strategie čištění historie.
Vnitřně se velení spoléhá na mechanismus přehrání v gitukterý se konsolidoval jako experimentální nástroj pro reprodukci commitů na jiné bázi bez dotyku s pracovním stromem. Část této práce spočívala v extrakci této logiky do společné knihovny, takže obě git history protože další budoucí funkce mohou těžit z modulárnější infrastruktury, kterou lze snadněji automatizovat pomocí skriptů nebo nástrojů třetích stran.
Konfigurační hooky: sdílení a kombinování automatizací
Další pozoruhodnou novou funkcí Gitu 2.54 je možnost definovat hooky přímo v konfiguračních souborech, namísto spoléhání se pouze na skripty umístěné v adresáři .git/hooks nebo na trase vyznačené core.hooksPathTato změna výrazně usnadňuje sdílení kontrol mezi různými repozitáři, aniž by bylo nutné soubory replikovat ručně.
Doposud bylo pro použití například formátovače kódu nebo analyzátoru tajných kódů před každým commitem napříč více projekty nutné zkopírovat hook skript do každého repozitáře nebo použít externí nástroje pro správu hooků. S novým přístupem je možné definovat centrální háčky v ~/.gitconfig nebo v /etc/gitconfig firemní a aby byly tyto uplatňovány v případě potřeby.
Definování hooků pomocí konfigurace a více příkazů na událost
Nová syntaxe je založena na konfiguračních klíčích stylů hook.<nombre>.command y hook.<nombre>.eventPrvní označuje, který příkaz bude proveden, a druhý specifikuje která událost hooku ji spouštínapříklad pre-commit nebo pre-pushProtože se jedná o standardní konfiguraci, mohou tato nastavení existovat současně na různých úrovních: uživatelské, systémové nebo repozitářové.
Git to navíc nyní umožňuje více hooků je přiřazeno stejné událostiJinými slovy, můžete definovat například linter a skener pověření, které se spustí na každém z nich. pre-commitaniž by bylo nutné je ručně kombinovat do jednoho skriptu. Git iteruje konfiguračními položkami v daném pořadí a provádí každý příkaz, přičemž si zároveň zachovává podporu pro klasický skript. $GIT_DIR/hooks, který na konci pokračuje v běhu, aby nenarušil předchozí konfigurace.
Správa, deaktivace a interní modernizace háčků
Pro kontrolu aktivních hooků a jejich původu je použit následující příkaz git hook listkterý ukazuje původ každého z nich, což je užitečné při správě centralizované konfigurace V korporátním prostředí, pokud konkrétní repozitář potřebuje vyloučit hook zděděný z globálního souboru, stačí nastavit hook.<nombre>.enabled = false, aniž by bylo nutné mazat nebo upravovat původní konfiguraci.
Pod kapotou má Git sjednocený a modernizovaný způsob, jakým zpracovává mnoho svých interních háčkůNěkolik integračních bodů, které byly dříve spravovány pomocí ad hoc tras, jako například hooky pro pre-push, post-rewrite nebo ty z receive-packNyní používají nové rozhraní hooks API. To nejen přináší konzistenci, ale také usnadňuje prostředím pro kontinuální integraci nebo platformám pro tvorbu kódu adaptaci na budoucí změny, aniž by bylo nutné přepisovat specifické integrace.
Geometrická údržba jako výchozí strategie
V předchozích verzích Git zaváděl tzv. strategii geometrický v git maintenanceTato strategie, navržená tak, aby snížila náklady na přebalování ve velkých repozitářích, analyzuje existující soubory packfile a hledá kombinace, které tvoří geometrickou posloupnost podle počtu objektů, a zhušťuje jejich obsah, aniž by bylo nutné pokaždé provádět kompletní uvolňování paměti.
S Gitem 2.54 se tento přístup stává výchozí možnost pro ruční údržbuKdyž to běží git maintenance run Bez specifikace strategie se automaticky zvolí geometrický přístup, místo přímého uchýlení se ke klasickému úkolu gc který se snaží seskupit vše do jednoho balíčku.
V praxi to znamená Úložiště jsou spravována efektivněji Od samého začátku je to obzvláště zajímavé pro projekty s dlouhou historií nebo pro organizace, které spravují rozsáhlé monorepozitáře. Geometrická strategie kombinuje inkrementální balíčky, když to dává smysl, a uchyluje se pouze k gc Dokončete, když se skutečně vše sloučí do jednoho packfile. Během procesu se graf commitů, reflogy a další pomocné struktury udržují aktuální.
Ti, kteří již nakonfigurovali maintenance.strategy = geometric Nevšimnou si žádných změn, protože tato preference je respektována. A ti, kteří dávají přednost pokračování v tradičním přístupu, mohou vynutit strategii gc konfigurování maintenance.strategy = gcčímž se zachovává kompatibilita s konzervativnějšími toky.
Vylepšení interaktivních a experimentálních příkazů
Kromě hlavních nových funkcí přináší Git 2.54 řadu změn zaměřených na... zdokonalit každodenní uživatelský zážitekzejména u příkazů, které se interaktivně používají ke správě změn.
Vylepšení v git přidávání -py nové možnosti navigace
Interaktivní režim git add -p a související příkazy dostávají různá vylepšení použitelnosti. Při navigaci mezi bloky pomocí kláves J y KGit nyní zobrazuje, zda je fragment byl dříve přijat nebo vynechánvyhnete se nutnosti ručně si pamatovat každé rozhodnutí.
Je také přidána možnost --no-auto-advancecož mění chování při práci s částmi souboru. Místo automatického přechodu na další soubor zůstává relace na aktuálním, což vám umožňuje používat < y > pro klidnější pohyb mezi soubory. Tento způsob práce je užitečný, když chcete před potvrzením zkontrolovat výběr změn jako celek.
git replay: větší vyspělost pro opětovné spuštění commitů
Experimentální pořadí přehrání v gituFunkce navržená pro replikaci commitů na nové bázi bez úpravy pracovního stromu se nadále rozšiřuje. V této verzi nyní provádí atomicky aktualizovat odkazy Ve výchozím nastavení namísto výpisu příkazů update-ref na standardním výstupu.
Kromě toho obsahuje režim --revert to umožňuje vrátit změny z řady commitůJe schopen zahodit commity, které se během procesu vyprázdní, a nyní podporuje přehrávání historie zpět ke kořenovému commitu. Tato vylepšení dobře zapadají do použití... git history, který se spoléhá na stejnou infrastrukturu, aby nabídl bezpečnější zážitek.
Nová možnost – trailer v git rebase
Další zajímavou úpravou je přidání --trailer en git rebasekterý využívá logiky interpret-trailers bod přidat stejný trailer ke každému overshotu commituMísto vytváření dlouhých příkazů s -x a volá do git commit --amend --no-edit --trailer=...Požadovaný trailer můžete přímo zadat při spuštění přetečení.
To výrazně zjednodušuje opakující se úkoly, jako je například vkládání řádků textu. Reviewed-by: nebo anotace podobné sérii commitů, což je běžné ve formálních procesech kontroly kódu používaných v distribuovaných týmech.
HTTP transport a správa podpisů: propracovanější chování
Pokud jde o síťovou komunikaci, Git 2.54 zavádí relevantní změny ve zpracování HTTP odpovědí a v interpretaci kryptografických podpisů spojených s commity a tagy.
Správa odpovědí HTTP 429 a konfigurovatelné opakované pokusy
HTTP transport v Gitu se učí správně interpretovat kódy. 429 „Příliš mnoho požadavků“Doposud, když server vracel chybu 429, bylo to považováno za fatální chybu a operace selhala. Počínaje touto verzí může Git požadavek zopakovat s respektováním hodnoty hlavičky. Retry-After pokud je k dispozici, nebo pomocí konfigurovatelného zpoždění prostřednictvím nové možnosti http.retryAfter.
Přidávají se také úpravy http.maxRetries y http.maxRetryTime, které umožňují ovládat maximální počet opakovaných pokusů a celkový čas strávený na nichTo je praktické v podnikových prostředích, kde je vyžadován přístup k přetíženým serverům nebo serverům s přísnými zásadami pro omezení požadavků, což pomáhá zefektivnit provoz. fetch y push být odolnější, aniž by to trestalo server.
Zpracování GPG podpisů s vypršenými klíči
Ohledně zabezpečení bylo opraveno potenciálně zavádějící chování: když byl commit podepsán GPG klíčem, jehož platnost následně vypršela, Git zobrazil podpis v alarmující červená barvaTo naznačovalo, že podpis byl neplatný. Pokud však byl podpis v dané době platný, měla by jeho platnost zůstat i v případě, že platnost klíče od té doby vypršela.
Git 2.54 tuto logiku upravuje a dále zvažuje Podpisy, které byly správně provedeny před vypršením platnosti klíče, jsou platné.Tím se zabrání zbytečným upozorněním. Poskytuje to přesnější obraz historie repozitáře, což je relevantní pro projekty s dlouhým životním cyklem, jako je institucionální nebo veřejněprávní software, který je udržován po mnoho let.
Nové možnosti inspekce a přizpůsobení historie
Několik příkazů určených k prozkoumávání historie se dočkalo vylepšení, která zvyšují jejich flexibilitu a umožňují přizpůsobenější výstupy pro každý případ.
`git log -L` se integruje se standardními nástroji pro porovnávání
Volba git log -LFunkce, která umožňuje sledovat vývoj rozsahu řádků v určitém souboru, byla znovu implementována tak, aby směrovala svůj výstup přes standardní mechanismus porovnávání GituDříve používal vlastní cestu, což ho znemožňovalo používat s velmi užitečnými možnostmi, jako je např. -S y -G (tzv. „krumpáče“) nebo s různými formáty nášivek.
Se změnou zavedenou v Gitu 2.54, -L stává se kompatibilním s pokročilé vyhledávání obsahu a formátů rozdílůvčetně --word-diff o --color-movedTímto způsobem lze výstup omezit na konkrétní funkci a zároveň filtrovat pouze commity, které přidávají nebo odebírají konkrétní symbol, což usnadňuje audity kódu a regresní analýzu.
git blame s výběrem algoritmu diff
Příkaz obviňovat gita, používá se k zobrazení, který commit zavedl který řádek souboru, učí se novou možnost --diff-algorithmTo vám umožňuje při výpočtu atribuce řádků vybrat si mezi různými algoritmy pro porovnání, jako je histogram, trpělivost nebo minimální.
V závislosti na typu změn, kterými soubor prošel, Výběr jednoho algoritmu před jiným může nabídnout jasnější výsledkyDíky tomu se snižuje šum ve vysoce aktivních historiích kódu. V prostředích, kde jsou podrobné kontroly vysoce ceněny, může tato úroveň kontroly znamenat zásadní rozdíl při zkoumání, kdo konkrétní blok kódu vytvořil.
Optimalizace úložiště a objektové databáze
Změny v této verzi se neomezují pouze na uživatelské rozhraní; značné úsilí bylo odvedeno i na fungování Gitu. interně organizuje a přistupuje k datůmTo má obzvláště významný dopad na velká úložiště.
Inkrementální indexy vícenásobných balení a zhutnění
Hovory vícebalíčkové inkrementální indexy (MIDX)Funkce, které byly již vylepšeny v předchozích verzích, nyní v Gitu 2.54 podporují zhutňování vrstev. Tento mechanismus kombinuje menší vrstvy MIDX spolu s jejich přidruženými bitmapami dosažitelnosti, aby řetězec vrstev zůstal na rozumné velikosti.
Tento krok je důležitý pro praktické využití inkrementálního MIDX v dlouhodobých repozitáříchnapříklad u velkých organizací nebo komunitních projektů s dlouholetou historií. Zhutnění vrstev snižuje složitost vyhledávání a zlepšuje výkon v operacích, jako je fetch, clone částečné nebo historické prohlídky.
Restrukturalizace objektové databáze (ODB)
Interně, a hloubkové refaktorování API objektové databáze (ODB). Nyní se používá zásuvný backendový design, ve kterém funkce jako například read_object(), write_object() o for_each_object() Jsou odesílány pomocí ukazatelů funkcí podle původu.
Ačkoli tato změna není pro koncového uživatele okamžitě viditelná, pokládá základy pro budoucí alternativní úložné backendy nebo flexibilnější konfigurace objektové databáze. Pro společnosti se specifickými požadavky na shodu s předpisy nebo integrací s vlastními úložnými systémy může tato modularita otevřít dveře k řešením na míru.
Vylepšení stavu, aliasů, doplňování a dalších podrobností
Git 2.54 také obsahuje řadu úprav, které, i když jsou menší, přispívají ke zdokonalení každodenního používání a přizpůsobení Gitu různým jazykovým a síťovým kontextům.
Stav gitu a porovnání s několika vzdálenými větvemi
Příkaz git status představuje možnost konfigurace status.compareBranchesVe výchozím nastavení tento příkaz zobrazoval, jak se aktuální větev porovnává s její nakonfigurovanou větví upstreamu, což je něco typického jako origin/mainS novou možností můžete požádat o porovnání s push větví nebo s oběma současně.
Tato funkce je navržena tak, aby trojúhelníkové toky, což je běžné při práci s forky: můžete stahovat z oficiálního vzdáleného serveru a odesílat změny na jiný, přičemž je vždy jasné, kolik commitů odděluje každou větev, což snižuje překvapení při synchronizaci repozitářů.
Alias s mezinárodními znaky
Doposud byly aliasy v Gitu omezeny na alfanumerické znaky ASCII a pomlčky, což bránilo použití názvů v jiných jazycích s diakritikou nebo jinými abecedami. Nová syntaxe podporuje prakticky jakýkoli znak kromě zalomení řádků a NUL. Porovnávání se provádí jako nezpracované bajty a rozlišují se velká a malá písmena. Systém automatického doplňování v shellu byl navíc aktualizován tak, aby tyto aliasy zvládal, což usnadňuje používání Gitu ve vícejazyčných týmech.
Backfill v Gitu je praktičtější v částečných klonech
Experimentální příkaz zásyp gituPříkaz používaný ke stahování chybějících objektů blob v částečných klonech je také vylepšen. Dříve příkaz vždy načítal dosažitelné objekty blob z HEAD v celém stromu, což by mohlo být v obzvláště velkých repozitářích nadměrné.
Git 2.54 přidává podporu pro zkontrolujte argumenty a specifikaci cestyaby zásyp mohl být omezen na rozsah historie (například main~100..main) nebo na určité konkrétní trasy (git backfill -- '*.c'), včetně zástupných znaků. Díky tomu je mnohem snazší pracovat s velkými částečnými klony, kde stačí doplnit historii pouze určité části kódu.
Další úpravy a detailní vylepšení
Seznam změn v Gitu 2.54 obsahuje dlouhý seznam drobných vylepšení. Mezi nimi je oprava algoritmu diff. histogramcož nyní brání fázi zhutňování v přesunu skupin změn způsobem, který by přerušil vybrané kotevní linie, a vytvořil tak čistší a méně redundantní rozdíly.
Nástroje jako například git config list , který se stává oficiálním způsobem pro výpis konfigurace, git merge-file který pak respektuje dostupnou konfiguraci i mimo repozitář, a několik souvisejících utilit git send-emailkteré získají podporu pro klientské certifikáty a pečlivější zacházení s uživatelem vybranými znakovými sadami.
Vývoj Gitu pokračuje dobrým tempem s verzí 2.54, která kombinuje viditelná vylepšení pro uživatele, jako nový řád git history nebo konfigurovatelné hooky, které vyžadují značnou práci na interní infrastruktuře systému. To vše ukazuje na robustnější a flexibilnější ekosystém, lépe připravený na výzvy stále větších repozitářů a rozmanitějších týmů.
