De aankomst de Git 2.54 Dit markeert een nieuwe stap in de evolutie van 's werelds meest gebruikte versiebeheersysteem voor softwareontwikkeling. De projectgemeenschap, met meer dan 130 mensen die aan deze cyclus hebben meegewerkt, heeft zich gericht op het vereenvoudigen van veelvoorkomende taken zonder de kracht die Git kenmerkt op te offeren.
Tot de nieuwe functies die wellicht het meest interessant zijn, behoort een nieuwe manier om Herschrijf de geschiedenis Op een veel directere manier gaat het om de mogelijkheid om gedeelde hooks te configureren vanuit gemeenschappelijke configuratiebestanden en interne verbeteringen die gericht zijn op snellere en gemakkelijker te onderhouden repositories, met name in grote of bedrijfsmatige projecten.
Git 2.54: Overzicht van de nieuwe release
Git 2.54 is een tussenversie op weg naar de toekomstige 3.0-branch, maar brengt wijzigingen met zich mee die het dagelijkse werk van veel ontwikkelaars beïnvloeden. Om te beginnen: Het experimentele commando `git history` is uitgebracht.Ontworpen voor eenvoudige bewerkingen om de geschiedenis te herschrijven. Bovendien is het hooksysteem uitgebreid en gemoderniseerd en kan het nu vanuit de instellingen worden beheerd; de geometrische onderhoudsstrategie is nu de standaard.
Daarnaast zijn er verbeteringen aangebracht in reeds bekende commando's zoals git add -p, git replay, git status of git rebaseNaast aanpassingen aan HTTP-transport, de manier waarop GPG-handtekeningen worden weergegeven en de interne werking van de objectdatabase. Hoewel veel van deze nieuwe functies geavanceerd zijn, zal hun impact merkbaar zijn in de dagelijkse werkprocessen van bedrijven, overheidsinstellingen en open source-projecten met grote repositories.
Nieuw experimenteel commando git history: eenvoudig commits herschrijven
Een van de belangrijkste toevoegingen in Git 2.54 is git geschiedenis, een nog experimenteel commando bedoeld voor gevallen waarin een interactieve rebase overbodig is. Tot nu toe was de standaardtool voor het wijzigen van de lokale geschiedenis git rebase -iZeer flexibel, maar ook complexer en vatbaarder voor conflicten die handmatig moeten worden opgelost.
met git geschiedenis Voor specifieke taken wordt een directere aanpak gezocht: bijvoorbeeld, een typefout corrigeren In het bericht van een commit van een paar wijzigingen geleden, of door een commit die te groot is geworden op te splitsen in tweeën. Het idee is om een ​​gecontroleerde manier te bieden om de geschiedenis aan te passen zonder de hele machinerie van een interactieve rebase met takenlijsten en tussenstappen te hoeven opzetten.
subcommando `reword`: pas commitberichten aan zonder de werkmap te wijzigen.
De eerste modus die de nieuwe orde introduceert is git history reword <commit>Bij het aanroepen opent Git de door de gebruiker geconfigureerde editor met de opgegeven commitberichtwaardoor je het direct kunt aanpassen. Wanneer je opslaat en de editor sluit, herschrijft Git die commit en werkt automatisch de branches die ervan afstammen bij, zodat ze naar de nieuwe versie verwijzen.
Het belangrijkste verschil met een interactieve rebase is dat `git history reword` raakt noch de werkmap, noch de index aan.Het werkt alleen de geschiedenis bij. Dit maakt het bijzonder nuttig in continue integratieomgevingen of geautomatiseerde scripts, omdat het zelfs kan werken met kale repositories, wat vaak voorkomt op interne codeservers van bedrijven of instellingen waar geen bijbehorende werkmap aanwezig is.
split-subcommando: een commit interactief splitsen
De tweede modus, git history split <commit>Het is ontworpen voor situaties waarin één enkele commit wijzigingen bevat die gescheiden moeten worden. Wanneer Git de wijzigingen weergeeft die bij die commit horen, kun je kiezen welke wijzigingen naar een nieuwe parent commit moeten worden geëxtraheerd, vergelijkbaar met hoe `git extract` werkt. git toevoegen -p bij het bepalen welke codefragmenten aan de index moeten worden toegevoegd.
Zodra de fragmenten zijn geselecteerd, maakt Git een Nieuwe commit met de gekozen stukken als ouder van het origineel.Het behoudt de niet-geselecteerde wijzigingen in de vorige commit. Vervolgens herschrijft het de afstammende branches zodat ze naar de nieuwe geschiedenisstructuur verwijzen. Ook deze bewerking wordt uitgevoerd zonder de huidige inhoud van de werkmap te wijzigen, waardoor de kans kleiner wordt dat de repository in een gecompliceerde tussenliggende staat achterblijft.
Beperkingen en compatibiliteit met andere workflows
Om het gedrag beheersbaar te houden, Git History ondersteunt geen geschiedenissen met merge-commits. en weigert verder te gaan als de bewerking resulteert in samenvoegingsconflicten. Het is ontworpen voor kleine aanpassingen, niet voor grootschalige herschrijvingen zoals die doorgaans met worden uitgevoerd. git rebase -i of agressievere strategieën voor het opschonen van de geschiedenis.
Internally is het commando afhankelijk van de mechanismen van git replayDit is uitgegroeid tot een experimenteel hulpmiddel om commits op een andere basis te reproduceren zonder de werkmap aan te raken. Een deel van dit werk bestond uit het overbrengen van die logica naar een gemeenschappelijke bibliotheek, zodat beide git history omdat andere toekomstige functionaliteiten kunnen profiteren van een meer modulaire infrastructuur die gemakkelijker te automatiseren is met scripts of tools van derden.
Configuratiegebaseerde hooks: automatiseringen delen en combineren
Een andere opvallende nieuwe functie van Git 2.54 is de mogelijkheid om Definieer hooks direct in de configuratiebestanden.in plaats van uitsluitend te vertrouwen op scripts die in de map zijn geplaatst. .git/hooks of op de route aangegeven door core.hooksPathDeze wijziging maakt het veel gemakkelijker om controles te delen tussen verschillende repositories zonder dat bestanden handmatig hoeven te worden gedupliceerd.
Tot nu toe was het, om bijvoorbeeld een codeformatter of een secrets analyzer vóór elke commit in meerdere projecten toe te passen, nodig om het hook-script naar elke repository te kopiëren of externe tools voor hook-beheer te gebruiken. Met de nieuwe aanpak is het mogelijk om dit te definiëren. centrale haken in ~/.gitconfig of in een /etc/gitconfig en dat deze waar nodig worden toegepast.
Hooks definiëren via configuratie en meerdere commando's per gebeurtenis.
De nieuwe syntaxis is gebaseerd op stijlconfiguratiesleutels. hook.<nombre>.command y hook.<nombre>.eventDe eerste geeft aan welke opdracht zal worden uitgevoerd, en de tweede specificeert welke hook-gebeurtenis het activeertbijvoorbeeld een pre-commit of pre-pushOmdat het een standaardconfiguratie betreft, kunnen deze instellingen op verschillende niveaus naast elkaar bestaan: gebruiker, systeem of repository.
Bovendien staat Git nu toe dat Er zijn meerdere hooks toegewezen aan hetzelfde evenement.Met andere woorden, je kunt bijvoorbeeld een linter en een credential scanner definiëren die op elk van beide worden uitgevoerd. pre-commitZonder dat ze handmatig in één script gecombineerd hoeven te worden. Git doorloopt de configuratie-items in volgorde en voert elk commando uit, terwijl de ondersteuning voor het klassieke script behouden blijft. $GIT_DIR/hooks, wat aan het einde doorloopt om eerdere configuraties niet te verstoren.
Beheer, deactivering en interne modernisering van haken.
Om te controleren welke hooks actief zijn en waar ze vandaan komen, wordt de volgende opdracht gebruikt. git hook listdie de oorsprong van elk ervan laat zien, iets wat handig is bij het beheren ervan. gecentraliseerde configuraties In bedrijfsomgevingen is het, als een specifieke repository een hook die is overgenomen van een globaal bestand moet uitsluiten, voldoende om dit in te stellen. hook.<nombre>.enabled = false, zonder dat de oorspronkelijke configuratie hoeft te worden verwijderd of gewijzigd.
Onder de motorkap heeft Git het volgende: Het heeft de manier waarop het veel van zijn interne verbindingen afhandelt, geünificeerd en gemoderniseerd.Verschillende integratiepunten die voorheen werden beheerd met ad-hocroutes, zoals hooks voor pre-push, post-rewrite of die van receive-packZe maken nu gebruik van de nieuwe hooks API. Dit zorgt niet alleen voor consistentie, maar maakt het ook gemakkelijker voor continue integratieomgevingen of codeforgingplatforms om zich aan te passen aan toekomstige wijzigingen zonder dat specifieke integraties opnieuw hoeven te worden geschreven.
Geometrische onderhoudsstrategie als standaardstrategie
In eerdere versies introduceerde Git de zogenaamde strategie. geometrisch binnen git maintenanceDeze strategie is ontworpen om de kosten van herverpakkingstaken in grote repositories te verlagen. De strategie analyseert bestaande packfiles en zoekt naar combinaties die een geometrische reeks vormen op basis van het aantal objecten, waardoor de inhoud wordt gecomprimeerd zonder dat er telkens een volledige garbage collection hoeft plaats te vinden.
Met Git 2.54 wordt deze aanpak de standaardoptie voor handmatig onderhoudAls het draait git maintenance run Zonder de strategie te specificeren, wordt automatisch de geometrische benadering gekozen, in plaats van direct terug te vallen op de klassieke taak van gc die probeert alles in één pakket te groeperen.
In de praktijk betekent dit dat Repositories worden efficiënter beheerd. Dit is vanaf het begin vooral interessant voor projecten met een lange geschiedenis of voor organisaties die grote monorepositories beheren. De geometrische strategie combineert incrementele pakketten wanneer dat zinvol is en maakt alleen gebruik van een gc Voltooi het proces wanneer alles daadwerkelijk wordt samengevoegd tot één enkel packfile. Tijdens dit proces worden de commit-grafiek, reflogs en andere hulpstructuren actueel gehouden.
Degenen die al geconfigureerd hadden maintenance.strategy = geometric Zij zullen geen veranderingen merken, aangezien die voorkeur wordt gerespecteerd. En degenen die de voorkeur geven aan de traditionele aanpak kunnen dat doen. dwing de strategie af gc configureren maintenance.strategy = gcwaardoor de compatibiliteit met meer conservatieve stromen behouden blijft.
Verbeteringen aan interactieve en experimentele commando's
Naast de belangrijkste nieuwe functies brengt Git 2.54 een flink aantal wijzigingen met zich mee die gericht zijn op De dagelijkse gebruikerservaring verbeterenvooral bij commando's die interactief worden gebruikt om wijzigingen te beheren.
Verbeteringen in git add -py nieuwe navigatieopties
De interactieve modus van git add -p en gerelateerde commando's krijgen diverse verbeteringen in gebruiksgemak. Bij het navigeren tussen codeblokken met behulp van de toetsen J y KGit laat nu zien of een fragment is eerder geaccepteerd of overgeslagenwaardoor je niet elke beslissing handmatig hoeft te onthouden.
De optie is ook toegevoegd. --no-auto-advanceDit verandert het gedrag wanneer je klaar bent met delen van een bestand. In plaats van automatisch naar het volgende bestand te gaan, blijft de sessie op het huidige bestand, waardoor je het kunt blijven gebruiken. < y > Om rustiger tussen bestanden te schakelen. Deze manier van werken is handig wanneer je de wijzigingen in hun geheel wilt bekijken voordat je ze bevestigt.
git replay: meer volwassenheid voor het opnieuw uitvoeren van commits
De experimentele volgorde git replayDe functie die is ontworpen om commits te repliceren op een nieuwe basis zonder de werkmap te wijzigen, blijft steeds meer mogelijkheden bieden. In deze versie voert de functie nu het volgende uit: Referenties atomisch bijwerken Standaard worden in plaats van commando's te dumpen update-ref op standaard output.
Daarnaast bevat het een modus --revert waardoor De wijzigingen van een reeks commits terugdraaienHet is in staat om commits te verwijderen die tijdens het proces leeg worden en ondersteunt nu het opnieuw afspelen van de geschiedenis tot aan de root-commit. Deze verbeteringen sluiten goed aan bij het gebruik van git history, dat gebruikmaakt van dezelfde infrastructuur om een ​​veiligere ervaring te bieden.
Nieuwe optie – trailer in git rebase
Een andere interessante aanpassing is de toevoeging van --trailer en git rebasendie gebruikmaakt van de logica van interpret-trailers voor Voeg dezelfde trailer toe aan elke overshot commit.In plaats van lange commando's te maken met -x en roept op tot git commit --amend --no-edit --trailer=...Je kunt de gewenste trailer direct specificeren bij het starten van de overrun.
Dit vereenvoudigt repetitieve taken, zoals het invoegen van tekstregels, aanzienlijk. Reviewed-by: of annotaties die lijken op een reeks commits, iets wat gebruikelijk is in formele codebeoordelingsprocessen die worden gebruikt in gedistribueerde teams.
HTTP-transport en handtekeningbeheer: verfijnder gedrag
Wat netwerkcommunicatie betreft, introduceert Git 2.54 relevante wijzigingen in de afhandeling van HTTP-reacties en in de interpretatie van cryptografische handtekeningen die aan commits en tags zijn gekoppeld.
HTTP 429-responsbeheer en configureerbare herhaalpogingen
Git's HTTP-transport leert de codes correct te interpreteren. 429 «Te veel aanvragen»Tot nu toe werd een 429-foutmelding van de server als een fatale fout beschouwd en mislukte de bewerking. Vanaf deze versie kan Git het verzoek opnieuw proberen, waarbij de headerwaarde behouden blijft. Retry-After indien aanwezig, of door gebruik te maken van een instelbare vertraging via de nieuwe optie http.retryAfter.
De aanpassingen worden ook toegevoegd. http.maxRetries y http.maxRetryTime, die toe staan Bepaal het maximale aantal herhaalpogingen en de totale tijd die daaraan wordt besteed.Dit is praktisch in bedrijfsomgevingen waar toegang nodig is tot overbelaste servers of servers met strikte aanvraagbeperkingen, waardoor de bedrijfsvoering wordt gestroomlijnd. fetch y push Wees veerkrachtiger zonder de server te straffen.
Het verwerken van GPG-handtekeningen met verlopen sleutels.
Wat betreft de beveiliging is een mogelijk misleidend gedrag gecorrigeerd: wanneer een commit werd ondertekend met een GPG-sleutel die vervolgens was verlopen, gaf Git de handtekening weer in een alarmerende rode kleurDit suggereerde dat de handtekening ongeldig was. Als de handtekening echter op dat moment geldig was, zou die geldigheid ook moeten blijven bestaan ​​als de sleutel inmiddels is verlopen.
Git 2.54 past deze logica aan en gaat verder met het overwegen van... Handtekeningen die correct zijn gemaakt voordat de sleutel verliep, zijn geldig.Dit voorkomt onnodige waarschuwingen. Het geeft een nauwkeuriger beeld van de geschiedenis van de repository, wat relevant is voor projecten met een lange levenscyclus, zoals institutionele of overheidssoftware die jarenlang wordt onderhouden.
Nieuwe inspectiemogelijkheden en aanpassing van de inspectiehistorie.
Verschillende commando's die zijn ontworpen om de geschiedenis te verkennen, zijn verbeterd, waardoor ze flexibeler zijn en voor elk geval een meer op maat gemaakte uitvoer mogelijk is.
`git log -L` integreert met de standaard diff-functionaliteit.
De keuze git log -LDe functie waarmee de evolutie van een reeks regels in een specifiek bestand kan worden gevolgd, is opnieuw geïmplementeerd om de uitvoer ervan via de volgende weg te leiden: standaard Git diff-mechanismeVoorheen gebruikte het een eigen pad, waardoor het incompatibel was met zeer nuttige opties zoals -S y -G (de zogenaamde "houwelen"), of met verschillende patchformaten.
Met de wijziging die is doorgevoerd in Git 2.54, -L wordt compatibel met geavanceerde inhoud en zoekopdrachten in verschillende formateninclusief --word-diff o --color-movedOp deze manier kan de uitvoer worden beperkt tot een specifieke functie en tegelijkertijd worden gefilterd op alleen commits die een specifiek symbool toevoegen of verwijderen, wat codeaudits en regressieanalyses vergemakkelijkt.
git blame met selectie van het diff-algoritme
Het commando krijg de schuld, dat gebruikt wordt om te zien welke commit elke regel van een bestand heeft geïntroduceerd, leert een nieuwe optie --diff-algorithmHiermee kunt u bij het berekenen van lijnattributie kiezen tussen verschillende diff-algoritmen, zoals histogram, patience of minimal.
Afhankelijk van het type wijzigingen dat een bestand heeft ondergaan, De keuze voor het ene algoritme boven het andere kan tot duidelijkere resultaten leiden.Dit vermindert de ruis in zeer actieve codegeschiedenissen. In omgevingen waar gedetailleerde reviews zeer gewaardeerd worden, kan dit niveau van controle het verschil maken bij het onderzoeken wie een bepaald codeblok heeft geïntroduceerd.
Opslagoptimalisatie en objectdatabases
De wijzigingen in deze versie beperken zich niet tot de gebruikersinterface; er is ook aanzienlijk werk verricht aan de werking van Git. organiseert en raadpleegt gegevens intern.Dit heeft met name een aanzienlijke impact op grote repositories.
Incrementele multipack-indexen en verdichting
De oproepen multi-pack incrementele indexen (MIDX)Git 2.54 biedt, naast verbeteringen in eerdere versies, nu ook ondersteuning voor layer compaction. Dit mechanisme combineert kleinere MIDX-lagen, samen met de bijbehorende reachability bitmaps, om de layer chain binnen redelijke grenzen te houden.
Deze stap is belangrijk voor Het praktisch maken van incrementele MIDX in langlopende repositorieszoals die van grote organisaties of gemeenschapsprojecten met een lange geschiedenis. Het comprimeren van de lagen vermindert de complexiteit van zoekopdrachten en verbetert de prestaties bij bewerkingen zoals... fetch, clone gedeeltelijke of historische inspecties.
Herstructurering van objectdatabases (ODB)
Internaal, een Grondige herstructurering van de objectdatabase-API (ODB). Nu wordt een pluggable backend-ontwerp gebruikt, waarin functies zoals read_object(), write_object() o for_each_object() Ze worden verzonden met behulp van functiepointers op basis van de oorsprong.
Hoewel deze verandering niet direct zichtbaar is voor de eindgebruiker, legt ze de basis voor toekomstige alternatieve opslagbackends of flexibelere objectdatabaseconfiguraties. Voor bedrijven met specifieke wettelijke vereisten of integratie met hun eigen opslagsystemen kan deze modulariteit de weg vrijmaken voor meer op maat gemaakte oplossingen.
Verbeteringen aan status, aliassen, backfill en andere details.
Git 2.54 bevat ook een aantal aanpassingen die, hoewel kleiner, bijdragen aan het verfijnen van het dagelijks gebruik en het aanpassen van Git aan diverse taalkundige en netwerkcontexten.
git status en vergelijking met verschillende externe branches
Het commando git status introduceert de configuratieoptie status.compareBranchesStandaard liet dit commando zien hoe de huidige branch zich verhield tot de geconfigureerde upstream, iets typisch zoals origin/mainMet de nieuwe optie kunt u een vergelijking aanvragen met de push-branch, of met beide tegelijk.
Deze functionaliteit is ontworpen om driehoekige stromenDit is gebruikelijk bij het werken met forks: je kunt downloaden van een officiële remote repository en wijzigingen naar een andere sturen, waarbij je altijd duidelijk bijhoudt hoeveel commits er tussen elke branch zitten. Dit vermindert verrassingen bij het synchroniseren van repositories.
Alias ​​met internationale tekens
Tot nu toe waren Git-aliassen beperkt tot ASCII-alfanumerieke tekens en koppeltekens, waardoor het gebruik van namen in andere talen met accenten of andere alfabetten werd belemmerd. De nieuwe syntax ondersteunt vrijwel elk teken, behalve regeleinden en NUL. De overeenkomst wordt gedaan op basis van ruwe bytes en is hoofdlettergevoelig. Bovendien is het autocomplete-systeem van de shell bijgewerkt om deze aliassen te ondersteunen, waardoor Git gemakkelijker te gebruiken is in meertalige teams.
Git backfill is praktischer bij gedeeltelijke klonen.
Het experimentele commando git backfillHet commando dat wordt gebruikt om ontbrekende blobs in gedeeltelijke klonen te downloaden, wordt ook verbeterd. Voorheen haalde het commando altijd bereikbare blobs op uit HEAD over de hele boomstructuur, wat in bijzonder grote repositories overbodig kan zijn.
Git 2.54 voegt ondersteuning toe voor review argumenten en padspecificatiezodat de backfill beperkt kan worden tot een bepaald historisch bereik (bijvoorbeeld, main~100..main) of naar bepaalde specifieke routes (git backfill -- '*.c'), inclusief wildcardpatronen. Dit maakt het veel gemakkelijker om te werken met grote, gedeeltelijke klonen, waarbij je alleen de geschiedenis van een specifiek deel van de code hoeft te voltooien.
Overige aanpassingen en gedetailleerde verbeteringen
De changelog van Git 2.54 bevat een lange lijst met kleine verbeteringen. Daaronder bevindt zich een correctie voor het diff-algoritme. histogramDit voorkomt nu dat de compactiefase groepen wijzigingen verplaatst op een manier die de geselecteerde ankerlijnen verbreekt, waardoor schonere en minder redundante verschillen ontstaan.
Gereedschappen zoals git config list , wat steeds meer wordt gezien als de officiële manier om configuraties weer te geven, git merge-file die vervolgens de beschikbare configuratie respecteert, zelfs buiten een repository, en diverse gerelateerde hulpprogramma's. git send-emaildie ondersteuning bieden voor clientcertificaten en een zorgvuldigere verwerking van door de gebruiker geselecteerde tekensets.
De ontwikkeling van Git zet zich in een goed tempo voort met versie 2.54, die een combinatie van verschillende functionaliteiten bevat. zichtbare verbeteringen voor de gebruiker, zoals de nieuwe orde git history of configureerbare hooks, die aanzienlijke aanpassingen aan de interne infrastructuur van het systeem vereisen. Dit alles wijst op een robuuster en flexibeler ecosysteem, beter voorbereid op de uitdagingen van steeds grotere repositories en meer diverse teams.
