In de afgelopen week de release van de nieuwe versie van het Git 2.23 gedistribueerde broncontrolesysteem werd gepresenteerd. In vergelijking met de vorige versie zijn er iets meer dan 500 wijzigingen aangebracht in deze nieuwe versie.
Maar tussen onlangs geïntroduceerde verbeteringen in deze nieuwe versie, degenen die de meeste aandacht krijgen zijn git switch y git restoreDeze zijn twee experimentele commando's specifiek die kan worden gebruikt om het commando tot op zekere hoogte te vervangen git checkout. Voor degenen die niet bekend zijn met git, zou je moeten weten dat dit een van de meest populaire, betrouwbare en krachtige versiebeheersystemen is die flexibele niet-lineaire ontwikkeltools biedt op basis van versievertakking en samenvoeging.
Om de integriteit van de historie en weerstand tegen wijzigingen achteraf te verzekeren, wordt een impliciete hash van alle voorgaande geschiedenis gebruikt bij elke commit, en individuele ontwikkelaars van commit en tags kunnen ook digitaal worden ondertekend.
Belangrijkste nieuwe kenmerken van git 2.23
In deze nieuwe versie van git de bovengenoemde experimentele commando's worden gepresenteerd "git switch y git restore'.
Deze nieuwe commando's zijn ontworpen om de functies te scheiden «git checkout» los, zoals takmanipulatie (verandering en creatie) en herstel van bestanden in de werkmap («git checkout $ commit - $ filename») Of direct in de verzamelplaats («--staging«, Heeft geen analoog in de«git checkout
git checkout is een commando waarmee je bijvoorbeeld branches kunt wijzigen of nieuwe branches in een repository kunt maken.
Als een gebruiker individuele bestanden wil bewerken of zelfs de bestandsnamen in de repository op hun harde schijf wil resetten zodat ze vergelijkbaar zijn met hun bestanden, kunnen ze ook git checkout gebruiken. Naast deze mogelijkheden kunnen andere acties worden uitgevoerd met het git checkout commando.
Het is vermeldenswaard dat, in tegenstelling tot «git checkout' "git restore» verwijdert niet-bijgehouden bestanden uit herstelde mappen (Standaard "–No-overlay").
met git restore, is het veel gemakkelijker om precies te bepalen welke bestanden zullen veranderen, hoe ze zullen veranderen en waar ze zullen veranderen. In feite, in plaats van het gecompliceerde commando te gebruiken git checkout, git restore biedt 2 opties om aan te geven waar de herstelde wijzigingen naartoe gaan.
Daarom, als u de parameter --worktree (of je specificeert niets), zullen de wijzigingen worden aangebracht in de repository op je harde schijf. Als u echter de parameter --staged, de wijzigingen gaan naar de index. Als u ten slotte beide parameters doorgeeft, gaan de wijzigingen naar de twee respectieve locaties.
In git 2.23 de optie "git merge --quit«, Die, zoals« –abort », stopt het samenvoegen van vertakkingen, maar laat de werkmap intact. Deze optie kan handig zijn als het de voorkeur verdient om een aantal van de wijzigingen die tijdens het handmatig samenvoegen zijn gemaakt als een aparte commit uit te voeren.
commando's git clone, git fetch y git push nu houden ze rekening met de aanwezigheid van commits in gekoppelde (alternatieve) repositories.
Opties «git blame --ignore-rev"En"--ignore-revs-file»Om commits over te slaan die kleine wijzigingen hebben aangebracht (bijvoorbeeld opmaakherstellingen);
Aan de andere kant vinden we de toevoeging van de optie «git cherry-pick --skip»Om het conflictcompromis over te slaan (opgeslagen analoog van de reeks«git reset y git cherry-pick --continue')
Vanaf deze versie git log zal standaard rekening houden met de wijzigingen die door mailmap zijn aangebracht, vergelijkbaar met wat er al gebeurt in git shortlog.
De kaartupdate operatie commit (core.commitGraph) ingediend in 2.18 werd aanzienlijk versneld. Het versnelde ook git voor elke referentie in het geval van het gebruik van meerdere sjablonen en verminderde het aantal aanroepen van auto-gc in "git fetch --multiple".
Configuratie is toegevoegd status.vooruitAchter, de optie instellen «git status - [no-] ahead-behind"Doorlopend.
«git branch --list»Toont nu altijd een aparte HEAD aan het begin van de lijst, ongeacht de locale.
Naast deze verbeteringen, deze nieuwe versie van Git kan nu de referenties van een andere oplossing gebruiken als onderdeel van de verificatie van het verbonden object wat kan gebeuren wanneer u een repository kloont en een andere specificeert tijdens het klonen of in een andere.
Si u wilt er meer over weten u kunt raadplegen de volgende link.