Vrystelling van die verspreide bronbeheerstelsel Git 2.22

Bekendgestel vrystelling van 'n verspreide bronbeheerstelsel git 2.22.0. Git is een van die gewildste, betroubare en hoëprestasie-weergawebeheerstelsels, wat buigsame nie-lineêre ontwikkelingsinstrumente bied wat gebaseer is op vertakking en samesmelting. Om die integriteit van geskiedenis en weerstand teen terugwerkende veranderinge te verseker, word implisiete hashing van die hele vorige geskiedenis in elke commit gebruik, en dit is ook moontlik om individuele etikette en commits te sertifiseer met digitale handtekeninge van ontwikkelaars.

In vergelyking met die vorige weergawe, het die nuwe weergawe 745 veranderinge ingesluit, voorberei met die deelname van 74 ontwikkelaars, waarvan 18 vir die eerste keer aan ontwikkeling deelgeneem het. Die belangrikste innovasies:

  • Beskikbaar sedert vrystelling 1.18, die nuwe commit rebase-modus "git rebase --rebase-merges" vervang die ou "--preserve-merges" opsie, wat nou afgekeur is. Die "git rebase" bewerking word gebruik om 'n reeks commits te vervang met 'n nuwe basis commit, byvoorbeeld om 'n aparte tak wat besig is om 'n nuwe kenmerk te ontwikkel na die huidige toestand van die meestertak te skuif, wat regstellings insluit wat na die tak bygevoeg is :

    o - o - o (my-kenmerk)

    /

    o - o - o - o - o (meester)

    o - o - o (my-kenmerk)

    /

    o - o - o - o - o (meester)

    Om die takstruktuur in 'n gemigreerde tak te bewaar, kon die "--preserve-merges" opsie voorheen gebruik word, wat, wanneer dit in interaktiewe modus uitgevoer word (git rebase -i --preserve-merges), die wysiging van die commit geskiedenis toegelaat het, maar het nie volledige bewaring van die bewaarplekstruktuur gewaarborg nie. Die nuwe "--rebase-merges"-modus laat jou toe om die struktuur van veranderinge in die tak wat gemigreer word te behou, terwyl dit 'n volledige reeks interaktiewe bewerkings verskaf, insluitend die verwydering, hergroepering en hernoeming van commits.

    Byvoorbeeld, "--rebase-merges" dit laat herlaai commits van 'n aparte tak na 'n nuwer meestertak, terwyl die takstruktuur in die gemigreerde tak gehandhaaf word, en maak 'n paar veranderinge aan die commit-notas dadelik.

  • Bygevoeg ondersteuning vir die skep van 'n nuwe tak gebaseer op die resultaat van die bepaling van die samesmeltingsbasis van twee ander takke (samevoegingsbasis, binding aan 'n gemeenskaplike voorouer) deur die konstruksies "git branch new A...B" en "git checkout -b new" te gebruik A...B", waarin "A ...B" die definisie van 'n samesmeltingsbasis tussen twee gespesifiseerde commits behels, soortgelyk aan hoe "git checkout A...B" die HEAD na die basis commit skuif en "diff A. ..B" wys die veranderinge tussen commit "B" en dieselfde as commit "A" "Ancestor.

    Byvoorbeeld, wanneer jy aan 'n aparte my-kenmerk-tak werk, kan hierdie kenmerk gebruik word wanneer jy van 'n ander tak wil begin, byvoorbeeld vanaf dieselfde plek in die meestertak waaruit die my-kenmerk-tak uitgeteken is. Voorheen het dit vereis om die veranderingslogboek handmatig te ondersoek, wat ongerieflik was as jy 'n groot geskiedenis van veranderinge gehad het, en dan "git merge-base master my-feature" te laat loop om die hash van die samesmeltingsbasis tussen die master- en my-feature-takke te bereken en die skep van 'n nuwe tak relatief tot die gemeenskaplike voorouer "git branch my-other-feature hash." In Git 2.22 kan jy die sintaksis "git branch my-other-feature A...B" gebruik om 'n tak relatief tot die samesmeltingsbasis van twee ander takke te skep;

  • Bygevoeg "git branch --show-current" opsie om die naam van die tak wat tydens die betaalhandeling verkry is, te vertoon;
  • Die opsie "git checkout —no-overlay - dir" is bygevoeg, wat dit moontlik maak om, wanneer 'n betaalhandeling uitgevoer word, die inhoud van die dir-gids na 'n vorm te bring wat ten volle ooreenstem met die toestand van die hooftak. Byvoorbeeld, as daar 'n lêer in die plaaslike kopie van die dir-gids is wat nie in die hooftak is nie, sal dit by verstek gelaat word wanneer "git checkout master - dir" uitgevoer word, en as die "--no-overlay ” opsie gespesifiseer word, dit sal uitgevee word;
  • Die "git diff"-opdrag gebruik 'n universele API vir die ontleding van opsies, wat dit moontlik maak om opsiehantering met ander git-nutsprogramme te verenig. Byvoorbeeld, in "git diff", het alle opsies nou hul antagoniste ("--funksie-konteks" en "--geen-funksie-konteks");
  • Het die vermoë bygevoeg om uitgebreide etikette wat aan commits gekoppel is, te filter in die "git log"-uitvoer ("sleepwa" - bykomende inligtingsvlae, soos Signed-off-by en Co-authored-by). Dit is moontlik om etikette volgens beide sleutel en waarde te filter, byvoorbeeld:
    "git log --pretty="%(trailers:key=Reviewed-by,valueonly)";

  • 'n Nuwe opsporingsenjin, Trace2, is bygevoeg, wat 'n meer buigsame en gestruktureerde uitvoerformaat bied. Trace2 laat jou toe om telemetrie oor uitgevoerde bedrywighede en prestasiedata in te samel vir meer gedetailleerde analise en ontfouting (die hanteerder word deur die gebruiker toegewys, geen data word ekstern gestuur nie);
  • Die “git bisect”-verslag is meer leesbaar gemaak, waarin problematiese commits nou duideliker uitgelig word en opsommende statistieke oor veranderinge vir elke lêer vertoon word (op die vlak van die aantal reëls wat verander is);
  • Die heuristiek vir die bepaling van gidshernoemings is herwerk om vals installering van hernoemingsetikette uit te skakel. Wanneer daar twyfel is, word sulke gidse nou as botsend gemerk;
  • 'n Waarskuwing word vertoon wanneer jy probeer om 'n merker op 'n ander merker te installeer, wat gewoonlik per ongeluk gedoen word en kan lei tot die opstel van die merker op die verkeerde commit (byvoorbeeld 'n konstruksie soos "git tag -f -m "opgedateerde boodskap" my-tag1 my-tag2″ sal daartoe lei dat 'n merker op die ou merker geskep word, terwyl die ontwikkelaar verwag het dat die nuwe merker geïnstalleer sou word op die commit waarna die ou merker verwys het);
  • Generasie is geaktiveer vir bitmapbewaarplekke (skyfgebaseerde "bereikbaarheid bitmaps"-struktuur), wat data stoor oor stelle voorwerpe wat beskikbaar is vir elke commit en jou toelaat om vinnig die teenwoordigheid van 'n basisvoorwerp te bepaal. Hierdie struktuur verminder die uitvoeringstyd van data-herwinning (git fetch) aansienlik.

Bron: opennet.ru

Voeg 'n opmerking