Programmering

5 avancerede Git-kommandoer til at opgradere dit Git-spil

Hvis du er udvikler i dag, er det sandsynligt, at du har lært Git, versionskontrolsystemet, der er kernen i moderne software-arbejdsgange. Du kender det grundlæggende - hvordan arkiver fungerer, hvordan man opretter filialer og begår ændringer, og hvordan man fletter disse ændringer og trækker anmodninger.

Men nu hvor du kender det grundlæggende, er det tid til at niveauere lidt - for at drage fordel af nogle af de mere kraftfulde funktioner i Git i din arbejdsgang. Her er fem avancerede Git-funktioner, der gør en del af din nuværende og fremtidige udviklingsindsats.

Forenkle forpligtelseshistorikker med git rebase

Når du har to grene i et projekt (f.eks. En udviklingsgren og en mastergren), som begge har ændringer, der skal kombineres, git fusion kommando er den naturlige og ligefremme måde at forene dem på. EN fusionere tilføjer udviklingshistorikken for den ene gren, når en fusion forpligter sig til den anden. Selvom dette bevarer begge historier i detaljer, kan det gøre projektets samlede historie vanskeligt at følge. I nogle tilfælde vil du muligvis have et enklere og renere resultat.

Det git rebase kommando fletter også to grene, men gør det lidt anderledes. EN git rebase omskriver den ene grenes begivenhedshistorie, så den anden gren inkorporeres i den fra det sted, hvor den blev oprettet. Dette giver en mindre støjende og mere lineær begivenhedshistorie for den gren. Men det betyder også, at potentielt nyttige detaljer om den anden gren og fusionsprocessen fjernes.

Til dette formål rebase bruges bedst, når du har flere privat filialer, som du vil konsolidere i en enkelt, ren forpligtelseshistorik, før du fletter den med en offentlig filial. På denne måde får du den fulde fordel afrebase - gøre en forpligtelseshistorie mere lineær og mindre støjende - uden at skjule vigtige detaljer om historien om forpligtelser til dit projekt.

Oprydning fusionerer med git merge - squash

En anden måde at foretage fletninger og efterfølgende forpligtelser på er mindre støjende ved at bruge - squash mulighed i git fusion. - squash tager alle forpligtelser fra en indgående gren og flader dem ud i en enkelt, konsolideret forpligtelse.

Skønheden ved en sammenpresset fletning er, at du kan vælge, hvordan du anvender de resulterende iscenesatte filer. Du kan bare begå hele sæt ændringer som en, eller du kan begå et par filer ad gangen, hvor ændringerne er nært beslægtede. En sammenpresset fletning er også nyttig, hvis begivenhedshistorikken for den indgående gren kun er nyttig inden for den gren, eller hvis den er fra en privat gren, der alligevel vil blive kasseret.

Som med en rebase, denne teknik fungerer bedst til at begå indre grene at mestre, men det er også velegnet til pull-anmodninger, hvis det er nødvendigt.

Fremskynd fejlsøgninger med git halveret

Subtile regressioner i kode er det sværeste at drille ud. Forestil dig, at du lige har tilføjet en test til din kodebase for at jage en fejl, men du er ikke sikker på, hvornår fejlen først dukkede op ... og du har hundreder eller endda tusinder af forpligtelser i dit arkiv. Detgit halveret kommando lader dig kraftigt reducere den mængde kode, du skal søge for at finde den forpligtelse, der oprettede fejlen.

Når du aktiverer halveres (git halveret start) du angiver to punkter i din kodebase for at begrænse din søgning: et hvor du ved, at ting er dårlige (HOVED, typisk), og en, hvor du ved, at ting stadig var gode. halveres vil tjekke en forpligtelse halvvejs mellem den dårlige og den gode, og lade dig køre dine tests. Denne binære underinddelingsproces gentages, indtil den viser den forpligtelse, der brød ting.

git halveret er en gave til store kodebaser med lange, komplekse begivenhedshistorikker, hvilket sparer dig for besværet med at skulle pote igennem hver sidste begivenhed i håb om, at du finder din fejl før eller senere. Ved meget mindst, det skærer ned med halvdelen af ​​mængden af ​​søgning og test, du skal gøre.

Ansøg igen forpligter sig til git cherry-pick

Mange avancerede git kommandoer er kun nyttige under snævert specifikke omstændigheder og ignoreres sikkert selv af moderat avancerede brugere. Men når du løber ind i en af ​​disse specifikke omstændigheder, betaler det sig at kende dem.

Overveje git cherry-pick. Det giver dig mulighed for at tage en given forpligtelse - enhver forpligtelse, fra enhver gren - og anvende den på en anden gren uden at skulle anvende andre ændringer fra historien om denne forpligtelse. Dette er nyttigt under nogle få vigtige omstændigheder:

  • Du forpligtede dig til den forkerte gren, og du vil hurtigt anvende den på den rigtige gren.
  • Du vil anvende en rettelse fra en gren til bagagerum, inden du fortsætter med andet arbejde med trunk-kode.

Bemærk, at du har nogle indstillinger udover direkte anvendelse af forpligtelsen, når du selektiv udvælgelse det. Hvis du passerer - ingen forpligtelse valgmulighed, f.eks. placeres det kirsebærplukkede engagement i iscenesættelsesområdet for den aktuelle gren.

Organiser projekter elegant med Git-undermoduler

Ligesom de fleste programmeringssprog giver mulighed for at importere pakker eller moduler, tilbyder Git en måde til automatisk at inkludere indholdet af et lager i et andet, en undermodul. Du kan oprette en underkatalog inde i en repo og automatisk udfylde den med indholdet af en anden repo, typisk ved at henvise til en bestemt kommit-hash af hensyn til konsistensen.

Bemærk, at Git-undermoduler fungerer bedst under følgende forhold:

  • De pågældende delmoduler ændres ikke ofte, eller de er låst til en bestemt forpligtelse. Ethvert arbejde en undermodul snarere end med en undermodul, skal styres separat.
  • Alle bruger en version af Git, der understøtter undermoduler og forstår de nødvendige trin for at arbejde med dem. For eksempel er undermodulmapper ikke altid udfyldt automatisk med indholdet af submodullageret. Du skal muligvis bruge git submodule opdatering kommando på repoen for at bringe alt opdateret.
$config[zx-auto] not found$config[zx-overlay] not found