release van een gedistribueerd broncontrolesysteem . Git is een van de meest populaire, betrouwbare en krachtige versiebeheersystemen en biedt flexibele, niet-lineaire ontwikkeltools op basis van vertakken en samenvoegen. Om de integriteit van de geschiedenis en weerstand tegen veranderingen met terugwerkende kracht te garanderen, wordt impliciete hashing van de gehele voorgaande geschiedenis in elke commit gebruikt, en is het ook mogelijk om individuele tags en commits te certificeren met digitale handtekeningen van ontwikkelaars.
Vergeleken met de vorige release bevatte de nieuwe versie 745 wijzigingen, voorbereid met de medewerking van 74 ontwikkelaars, van wie er 18 voor het eerst aan de ontwikkeling deelnamen. :
- De nieuwe commit rebase modus "git rebase --rebase-merges" is beschikbaar sinds release 1.18 en vervangt de oude "--preserve-merges" optie, die nu verouderd is. De "git rebase" operatie wordt gebruikt om een reeks commits te vervangen door een nieuwe basis commit, bijvoorbeeld om een aparte branch die een nieuwe functie ontwikkelt te verplaatsen naar de huidige status van de master branch, inclusief reparaties die na de branch zijn toegevoegd :
o - o - o (mijn-functie)
/
o - o - o - o - o (meester)
o - o - o (mijn-functie)
/
o - o - o - o - o (meester)
Om de branch structuur in een gemigreerde branch te behouden, kon voorheen de “--preserve-merges” optie gebruikt worden, die, wanneer uitgevoerd in interactieve modus (git rebase -i --preserve-merges), het bewerken van de commit geschiedenis toestond, maar garandeert geen volledig behoud van de repositorystructuur. Met de nieuwe “--rebase-merges”-modus kunt u de structuur van de wijzigingen in de branch die wordt gemigreerd behouden, terwijl u een volledig scala aan interactieve bewerkingen krijgt, waaronder het verwijderen, hergroeperen en hernoemen van commits.
Bijvoorbeeld: "--rebase-merges" upload commits opnieuw van een afzonderlijke branch naar een nieuwere master-branch, terwijl je de branch-structuur in de gemigreerde branch behoudt, en breng direct enkele wijzigingen aan in de commit-notities.
- Ondersteuning toegevoegd voor het maken van een nieuwe branch gebaseerd op het resultaat van het bepalen van de samenvoegbasis van twee andere branches (merge base, binding aan een gemeenschappelijke voorouder) met behulp van de constructies “git branch new A...B” en “git checkout -b new A...B”, waarbij “A ...B” het definiëren van een merge-basis tussen twee gespecificeerde commits inhoudt, vergelijkbaar met hoe "git checkout A...B" de HEAD naar de basis-commit verschuift en "diff A. ..B" toont de veranderingen tussen commit "B" en dezelfde als commit "A" "Ancestor.
Als u bijvoorbeeld aan een afzonderlijke my-feature branch werkt, kan deze functie worden gebruikt als u vanuit een andere branch wilt starten, bijvoorbeeld vanaf dezelfde plaats in de master branch van waaruit de my-feature branch is uitgecheckt. Voorheen vereiste dit het handmatig onderzoeken van het wijzigingslogboek, wat lastig was als je een lange geschiedenis van wijzigingen had, en vervolgens "git merge-base master my-feature" uit te voeren om de hash van de merge-basis tussen de master- en my-feature-takken te berekenen en het creëren van een nieuwe branch relatief aan de gemeenschappelijke voorouder “git branch my-other-feature hash.” In Git 2.22 kun je de syntaxis "git branch my-other-feature A...B" gebruiken om een branch te creëren die relatief is ten opzichte van de samenvoegbasis van twee andere branches;
- Toegevoegd "git branch --show-current" optie om de naam van de branch verkregen tijdens het afrekenen weer te geven;
- De “git checkout —no-overlay — dir” optie toegevoegd, die het mogelijk maakt, bij het uitvoeren van een checkout operatie, om de inhoud van de dir directory naar een vorm te brengen die volledig overeenkomt met de status van de master branch. Als er bijvoorbeeld een bestand in de lokale kopie van de map dir staat dat niet in de master branch staat, dan zal dit standaard bij het uitvoeren van “git checkout master - dir” blijven staan, en als de melding “--no-overlay ” optie is opgegeven, wordt deze verwijderd;
- Het "git diff" commando gebruikt een universele API voor het parseren van opties, wat het mogelijk maakt om de afhandeling van opties te verenigen met andere git-hulpprogramma's. In “git diff” hebben alle opties nu bijvoorbeeld hun antagonisten (“--function-context” en “--no-function-context”);
- De mogelijkheid toegevoegd om uitgebreide tags te filteren die aan commits zijn gekoppeld in de “git log” uitvoer (“trailer” - aanvullende informatievlaggen, zoals Ondertekend-door en Co-auteur-door). Het is mogelijk om labels te filteren op zowel sleutel als waarde, bijvoorbeeld:
"git log --pretty="%(trailers:key=Beoordeeld door,valueonly)"; - Er is een nieuwe traceringsengine toegevoegd, Trace2, die een flexibeler en gestructureerder uitvoerformaat biedt. Met Trace2 kunt u telemetrie verzamelen over uitgevoerde bewerkingen en prestatiegegevens voor meer gedetailleerde analyse en foutopsporing (de handler wordt toegewezen door de gebruiker, er worden geen gegevens extern verzonden);
- Het “git bisect”-rapport is leesbaarder gemaakt, waarin problematische commits nu duidelijker worden benadrukt en samenvattende statistieken over wijzigingen voor elk bestand worden weergegeven (op het niveau van het aantal gewijzigde regels);
- De heuristieken voor het bepalen van het hernoemen van directory's zijn herwerkt om valse installatie van hernoemingslabels te elimineren. Bij twijfel worden dergelijke mappen nu als conflicterend gemarkeerd;
- Er wordt een waarschuwing weergegeven als je probeert een tag op een andere tag te installeren, wat meestal per ongeluk wordt gedaan en kan leiden tot het instellen van de tag op de verkeerde commit (bijvoorbeeld een constructie als “git tag -f -m “updated message” my-tag1 my-tag2″ zal resulteren in het aanmaken van een tag op de oude tag, terwijl de ontwikkelaar verwachtte dat de nieuwe tag geïnstalleerd zou worden op de commit waarnaar de oude tag verwijst);
- Het genereren is ingeschakeld voor bitmaprepository's (op schijf gebaseerde "bereikbaarheidsbitmaps"-structuur), die gegevens opslaan over sets objecten die beschikbaar zijn voor elke commit en waarmee u snel de aanwezigheid van een basisobject kunt bepalen. Deze structuur vermindert de uitvoeringstijd van gegevensophaalbewerkingen (git fetch) aanzienlijk.
Bron: opennet.ru