Ankomsten de Git 2.54 Detta markerar ett nytt steg i utvecklingen av världens mest använda versionshanteringssystem för mjukvaruutveckling. Projektgemenskapen, med över 130 personer som samarbetar i denna cykel, har fokuserat på att förenkla vanliga uppgifter utan att offra den kraft som kännetecknar Git.
Bland de nya funktioner som kan vara av mest intresse finns ett nytt sätt att skriva om historien På ett mycket mer direkt sätt, möjligheten att konfigurera delade hooks från gemensamma konfigurationsfiler och interna förbättringar som syftar till snabbare och enklare att underhålla repositorier, särskilt i stora eller företagsprojekt.
Git 2.54: Översikt över den nya utgåvan
Git 2.54 är en mellanliggande version på väg mot den framtida 3.0-grenen, men den medför förändringar som påverkar det dagliga arbetet för många utvecklare. För det första, Det experimentella kommandot git history har släpptsUtformad för enkla historikomskrivningsoperationer. Dessutom har hook-systemet utökats och moderniserats och kan nu hanteras från inställningarna; den geometriska underhållsstrategin är nu standard.
Dessutom ingår förbättringar i redan kända kommandon som t.ex. git add -p, git replay, git status eller git rebasesamt justeringar av HTTP-transport, hur GPG-signaturer visas och objektdatabasens interna funktionssätt. Även om många av dessa nya funktioner är avancerade, kommer deras inverkan att märkas i vanliga arbetsflöden i företag, offentliga förvaltningar och projekt med öppen källkod med stora arkiv.
Ny git-historik för experimentella kommandon: enkel omskrivning av commits
Ett av de viktigaste tilläggen i Git 2.54 är git-historik, ett fortfarande experimentellt kommando avsett att täcka fall där det är överdrivet att använda en interaktiv rebase. Fram tills nu har det vanligaste verktyget för att modifiera den lokala historiken varit git rebase -i, mycket flexibel men också mer komplex och benägen att lämna användaren i motstridiga tillstånd som måste lösas manuellt.
med git-historik En mer direkt metod eftersträvas för specifika uppgifter: till exempel, rätta ett stavfel i meddelandet från en commit från några ändringar sedan, eller genom att dela upp en commit som har blivit för stor i två. Tanken är att erbjuda ett kontrollerat sätt att justera historiken utan att behöva ställa in hela maskineriet för en interaktiv rebase med uppgiftslistor och mellanliggande steg.
omformulera delkommando: justera commit-meddelanden utan att röra arbetsträdet
Det första läget som den nya ordern lanserar är git history reword <commit>När Git anropas öppnar den användarkonfigurerade editorn med angivet commit-meddelandeså att du kan ändra den direkt. När du sparar och stänger editorn skriver Git om den commiten och uppdaterar automatiskt grenarna som härstammar från den för att peka på den nya versionen.
Den viktigaste skillnaden jämfört med en interaktiv rebase är att `git history reword` berör varken arbetsträdet eller indexetDen uppdaterar bara historiken. Detta gör den särskilt användbar i miljöer med kontinuerlig integration eller automatiserade skript, eftersom den till och med kan fungera på bara repositories, vilket är vanligt i interna kodservrar hos företag eller institutioner där det inte finns något associerat arbetsträd.
delkommandot split: dela en commit interaktivt
Det andra läget, git history split <commit>Den är utformad för situationer där en enskild commit innehåller ändringar som ska separeras. När Git körs visar den de ändringar som är associerade med den commiten och låter dig välja vilka som ska extraheras till en ny överordnad commit, ungefär som hur `git extract` fungerar. git add -p när man bestämmer vilka kodbitar som ska läggas till i indexet.
När fragmenten är valda skapar Git en Ny commit med hunks valda som förälder till originaletDen behåller de omarkerade ändringarna i den föregående commiten. Sedan skriver den om de underordnade grenarna så att de pekar på den nya historikstrukturen. Återigen körs operationen utan att ändra det aktuella innehållet i arbetsträdet, vilket minskar sannolikheten för att lämna arkivet i ett komplicerat mellanläge.
Begränsningar och kompatibilitet med andra arbetsflöden
För att hålla beteendet kontrollerbart, git history stöder inte historiker med merge commits och vägrar att fortsätta om operationen resulterar i sammanslagningskonflikter. Den är utformad för mindre justeringar, inte för massiva omskrivningar som de som vanligtvis hanteras med git rebase -i eller mer aggressiva strategier för historikrensning.
Internt förlitar sig kommandot på maskineriet av git-uppspelningvilket har konsoliderats som ett experimentellt verktyg för att reproducera commits på en annan bas utan att vidröra arbetsträdet. En del av detta arbete har bestått i att extrahera den logiken till ett gemensamt bibliotek, så att båda git history eftersom andra framtida funktioner kan dra nytta av en mer modulär infrastruktur som är enklare att automatisera från skript eller tredjepartsverktyg.
Konfigurationsbaserade hooks: delning och kombination av automatiseringar
En annan anmärkningsvärd ny funktion i Git 2.54 är möjligheten att definiera hooks direkt i konfigurationsfilernaistället för att enbart förlita sig på skript placerade i katalogen .git/hooks eller på den rutt som anges av core.hooksPathDen här ändringen gör det mycket enklare att dela kontroller mellan olika databaser utan att behöva replikera filer manuellt.
Fram tills nu, för att till exempel använda en kodformaterare eller en hemlighetsanalysator före varje commit över flera projekt, var det nödvändigt att kopiera hook-skriptet till varje repository eller använda externa hook-hanteringsverktyg. Med den nya metoden är det möjligt att definiera centrala krokar i ~/.gitconfig eller i en /etc/gitconfig företag och att dessa tillämpas där det är nödvändigt.
Definiera hooks med konfiguration och flera kommandon per händelse
Den nya syntaxen är baserad på stilkonfigurationsnycklar hook.<nombre>.command y hook.<nombre>.eventDet första anger vilket kommando som ska köras, och det andra anger vilken hook-händelse utlöser dettill exempel en pre-commit eller ett pre-pushEftersom det är en standardkonfiguration kan dessa inställningar samexistera på olika nivåer: användare, system eller databas.
Dessutom tillåter Git nu det flera krokar är tilldelade samma händelseMed andra ord kan du till exempel definiera en linter och en autentiseringskontroll som ska köras på varje pre-commitutan att behöva kombinera dem manuellt till ett enda skript. Git itererar igenom konfigurationsposterna i ordning och kör varje kommando, samtidigt som stödet för det klassiska skriptet bibehålls. $GIT_DIR/hooks, som fortsätter att köras i slutet för att inte förstöra tidigare konfigurationer.
Hantering, deaktivering och intern modernisering av krokar
För att kontrollera vilka krokar som är aktiva och var de kommer ifrån, används följande kommando git hook listvilket visar ursprunget för var och en, något användbart vid hantering centraliserade konfigurationer I företagsmiljöer, om ett specifikt arkiv behöver exkludera en krok som ärvts från en global fil, räcker det att ställa in hook.<nombre>.enabled = falseutan att behöva ta bort eller ändra den ursprungliga konfigurationen.
Under huven har Git enhetligt och moderniserat hur det hanterar många av sina interna krokarFlera integrationspunkter som tidigare hanterades med ad hoc-rutter, såsom hooks för pre-push, post-rewrite eller de av receive-packDe använder nu det nya Hooks API:et. Detta ger inte bara konsekvens, utan gör det också enklare för kontinuerliga integrationsmiljöer eller kodformningsplattformar att anpassa sig till framtida förändringar utan att behöva skriva om specifika integrationer.
Geometriskt underhåll som standardstrategi
I tidigare versioner introducerade Git den så kallade strategin geometrisk inom git maintenanceDenna strategi är utformad för att minska kostnaden för ompackning av uppgifter i stora arkiv. Den analyserar befintliga packfiler och letar efter kombinationer som bildar en geometrisk progression efter antal objekt, vilket kondenserar deras innehåll utan att behöva utföra en fullständig sophämtning varje gång.
Med Git 2.54 blir detta tillvägagångssätt standardalternativet för manuellt underhållNär den körs git maintenance run Utan att specificera strategin väljs automatiskt den geometriska metoden, istället för att direkt tillgripa den klassiska uppgiften att gc som försöker samla allt i ett enda paket.
I praktiken betyder det det Arkiv underhålls mer effektivt Från början är detta särskilt intressant för projekt med lång historia eller för organisationer som hanterar stora monorepositories. Den geometriska strategin kombinerar inkrementella paket när det är meningsfullt och använder sig endast av en gc Färdigställs när den faktiskt ska konsolidera allt till en enda packfile. Under processen hålls commit-grafen, refloggar och andra hjälpstrukturer uppdaterade.
De som redan hade konfigurerat maintenance.strategy = geometric De kommer inte att märka några förändringar, eftersom den preferensen respekteras. Och de som föredrar att fortsätta med den traditionella metoden kan tvinga fram strategin gc konfigurera maintenance.strategy = gcvilket bibehåller kompatibilitet med mer konservativa flöden.
Förbättringar av interaktiva och experimentella kommandon
Utöver de viktigaste nya funktionerna medför Git 2.54 en rad förändringar som syftar till att förfina den dagliga användarupplevelsensärskilt i kommandon som används interaktivt för att hantera ändringar.
Förbättringar i git add -py nya navigeringsalternativ
Det interaktiva läget för git add -p och relaterade kommandon får olika användbarhetsförbättringar. När du navigerar mellan objekt med hjälp av tangenterna J y KGit visar nu om ett fragment har accepterats eller hoppats över tidigareatt slippa komma ihåg varje beslut manuellt.
Alternativet läggs också till --no-auto-advancevilket ändrar beteendet när man avslutar med bitar av en fil. Istället för att automatiskt gå vidare till nästa fil, stannar sessionen kvar på den aktuella, vilket gör att du kan använda < y > för att navigera mellan filer lugnare. Detta arbetssätt är användbart när du vill granska hela urvalet av ändringar innan du bekräftar dem.
git replay: mer mognad för att återexekvera commits
Den experimentella ordningen git-uppspelningFunktionen som är utformad för att replikera commits på en ny bas utan att modifiera arbetsträdet fortsätter att få nya funktioner. I den här versionen utför den nu atomiskt uppdatera referenser Som standard, istället för dumpkommandon update-ref på standardutgång.
Dessutom innehåller den ett läge --revert så återställ ändringarna från en rad commitsDen kan ta bort commits som blir tomma under processen och stöder nu uppspelning av historiken tillbaka till rot-commiten. Dessa förbättringar passar bra med användningen av git history, som förlitar sig på samma infrastruktur för att erbjuda en säkrare upplevelse.
Nytt alternativ – trailer i git rebase
En annan intressant justering är tillägget av --trailer en git rebasesom utnyttjar logiken i interpret-trailers till lägg till samma trailer till varje overshot-commitIstället för att bygga långa kommandon med -x och ringer till git commit --amend --no-edit --trailer=...Du kan direkt ange önskad släpvagn när du startar överkörningen.
Detta förenklar avsevärt repetitiva uppgifter, som att införliva textrader Reviewed-by: eller anteckningar som liknar en serie commits, något som är vanligt i formella kodgranskningsprocesser som används i distribuerade team.
HTTP-transport och signaturhantering: mer förfinat beteende
När det gäller nätverkskommunikation introducerar Git 2.54 relevanta förändringar i hanteringen av HTTP-svar och i tolkningen av kryptografiska signaturer associerade med commits och taggar.
HTTP 429-svarshantering och konfigurerbara återförsök
Gits HTTP-transport lär sig att tolka koderna korrekt 429 «För många förfrågningar»Fram tills nu, när en server returnerade ett 429-fel, ansågs det vara ett allvarligt fel och operationen misslyckades. Från och med den här versionen kan Git försöka igen begäran samtidigt som headervärdet respekteras. Retry-After om sådan finns, eller med hjälp av en konfigurerbar fördröjning via det nya alternativet http.retryAfter.
Justeringarna läggs också till http.maxRetries y http.maxRetryTime, som tillåter kontrollera det maximala antalet återförsök och den totala tiden som spenderas på demDetta är praktiskt i företagsmiljöer där åtkomst krävs till överbelastade servrar eller servrar med strikta policyer för begränsning av förfrågningar, vilket bidrar till att effektivisera verksamheten. fetch y push vara mer motståndskraftig utan att straffa servern.
Hantera GPG-signaturer med utgångna nycklar
Angående säkerhet har ett potentiellt vilseledande beteende korrigerats: när en commit signerades med en GPG-nyckel som senare hade löpt ut, visade Git signaturen i en alarmerande röd färgDetta tydde på att signaturen var ogiltig. Om signaturen däremot var giltig vid tidpunkten, borde den giltigheten bestå även om nyckeln sedan dess har löpt ut.
Git 2.54 justerar denna logik och fortsätter med att beakta Signaturer som gjordes korrekt innan nyckeln gick ut är giltiga.Detta undviker onödiga varningar. Det ger en mer korrekt bild av arkivets historik, vilket är relevant för projekt med långa livscykler, såsom institutionell eller offentlig förvaltningsprogramvara som underhålls i många år.
Nya inspektionsfunktioner och anpassning av historik
Flera kommandon som är utformade för att utforska historik får förbättringar som ökar deras flexibilitet och möjliggör mer skräddarsydda utdata för varje enskilt fall.
`git log -L` integreras med standard diff-maskineri
Alternativet git log -LFunktionen som gör det möjligt att spåra utvecklingen av ett radintervall i en specifik fil har implementerats på nytt för att dirigera dess utdata genom standard Git diff-mekanismTidigare använde den sin egen sökväg, vilket gjorde den inkompatibel med mycket användbara alternativ som t.ex. -S y -G (de så kallade "hackorna"), eller med olika patchformat.
Med ändringen som introducerades i Git 2.54, -L blir kompatibel med avancerade innehålls- och diff-formatsökningarinklusive --word-diff o --color-movedPå så sätt kan utdata begränsas till en specifik funktion och samtidigt filtreras endast för commits som lägger till eller tar bort en specifik symbol, vilket underlättar kodgranskningar och regressionsanalys.
git blame med diff-algoritmval
Kommandot git skyll, används för att se vilken commit som introducerade varje rad i en fil, lär sig ett nytt alternativ --diff-algorithmDetta låter dig välja mellan olika diff-algoritmer, såsom histogram, tålamod eller minimal, när du beräknar linjeattribution.
Beroende på vilken typ av ändringar en fil har genomgått, Att välja en algoritm framför en annan kan ge tydligare resultatDetta minskar brus i mycket aktiva kodhistoriker. I miljöer där detaljerade granskningar värderas högt kan denna kontrollnivå göra hela skillnaden när man undersöker vem som introducerade ett visst kodblock.
Lagringsoptimering och objektdatabaser
Ändringarna i den här versionen är inte begränsade till användargränssnittet; det har också gjorts avsevärt arbete med hur Git fungerar. organiserar och åtkommer data interntDetta har en särskilt betydande inverkan på stora arkiv.
Stegvisa flerpacksindex och komprimering
Samtal flerpacks inkrementella index (MIDX)Git 2.54 har redan förbättrats och inkluderar nu stöd för lagerkomprimering. Denna mekanism kombinerar mindre MIDX-lager, tillsammans med deras tillhörande nåbarhetsbitmappar, för att hålla lagerkedjan på en rimlig storlek.
Detta steg är viktigt för göra inkrementell MIDX praktisk i långlivade arkivsåsom de som rör stora organisationer eller samhällsprojekt med många års historia. Att komprimera lagren minskar komplexiteten i sökningar och förbättrar prestandan i operationer som fetch, clone partiella eller historiska inspektioner.
Omstrukturering av objektdatabasen (ODB)
Internt, en djupgående refaktorering av objektdatabasens API (ODB). Nu används en pluggbar backend-design, där funktioner som read_object(), write_object() o for_each_object() De skickas med hjälp av funktionspekare efter ursprung.
Även om denna förändring inte är omedelbart synlig för slutanvändaren, lägger den grunden för framtida alternativa lagringsbackends eller mer flexibla objektdatabaskonfigurationer. För företag med specifika krav på regelefterlevnad eller integration med sina egna lagringssystem kan denna modularitet öppna dörren till mer skräddarsydda lösningar.
Förbättringar av status, alias, reservuppgifter och andra detaljer
Git 2.54 innehåller också ett antal justeringar som, om än mindre, bidrar till att förfina den dagliga användningen och anpassa Git till varierande språkliga och nätverksmässiga sammanhang.
git-status och jämförelse med flera fjärrgrenar
Kommandot git status debuterar konfigurationsalternativet status.compareBranchesSom standard visade det här kommandot hur den aktuella grenen jämförde sig med dess konfigurerade uppströms, något typiskt som origin/mainMed det nya alternativet kan du begära en jämförelse med push-grenen, eller med båda samtidigt.
Denna funktion är utformad för att triangulära flöden, vanligt när man arbetar med forks: du kan ladda ner från en officiell fjärrkontroll och skicka ändringar till en annan, och hela tiden ha klart för dig hur många commits som skiljer varje branch åt, vilket minskar överraskningar vid synkronisering av repositories.
Alias ​​med internationella tecken
Fram tills nu har Git-alias varit begränsade till alfanumeriska ASCII-tecken och bindestreck, vilket förhindrar användning av namn på andra språk med accenter eller andra alfabet. Den nya syntaxen stöder praktiskt taget alla tecken förutom radbrytningar och NUL. Matchning görs som råa byte och är skiftlägeskänslig. Dessutom har skalets autokompletteringssystem uppdaterats för att hantera dessa alias, vilket gör Git enklare att använda i flerspråkiga team.
Git-återfyllning är mer praktisk i partiella kloner
Det experimentella kommandot git-återfyllningKommandot som används för att ladda ner saknade blobbar i partiella kloner förstärks också. Tidigare hämtade kommandot alltid nåbara blobbar från HEAD genom hela trädet, vilket kan vara överdrivet i särskilt stora databaser.
Git 2.54 lägger till stöd för granska argument och sökvägsspecifikationså att återfyllningen kan begränsas till ett visst historikintervall (till exempel main~100..main) eller till vissa specifika rutter (git backfill -- '*.c'), inklusive jokerteckenmönster. Detta gör det mycket mer hanterbart att arbeta med stora partiella kloner där du bara behöver slutföra historiken för en specifik del av koden.
Andra justeringar och detaljerade förbättringar
Git 2.54-ändringsloggen innehåller en lång lista med små förbättringar. Bland dem finns en fix för diff-algoritmen. histogramvilket nu förhindrar att komprimeringsfasen flyttar grupper av ändringar på ett sätt som bryter de valda ankarlinjerna, vilket producerar renare och mindre redundanta differenser.
Verktyg som git config list , vilket håller på att etableras som det officiella sättet att lista konfiguration, git merge-file som sedan respekterar den tillgängliga konfigurationen även utanför ett repository, och flera relaterade verktyg git send-emailsom får stöd för klientcertifikat och mer noggrann hantering av användarvalda teckenuppsättningar.
Gits utveckling fortsätter i god takt med version 2.54, som kombinerar synliga förbättringar för användaren, liksom den nya ordningen git history eller konfigurerbara hooks, vilket kräver betydande arbete på systemets interna infrastruktur. Allt detta pekar mot ett mer robust och flexibelt ekosystem, bättre förberett för utmaningarna med allt större databaser och mer diversifierade team.
