Programmering

5 avanserte Git-kommandoer for å øke Git-spillet ditt

Hvis du er en utvikler i dag, er det sannsynlig at du har lært Git, versjonskontrollsystemet som er kjernen i moderne arbeidsflyter for programvare. Du kjenner det grunnleggende - hvordan arkiver fungerer, hvordan du lager grener og begår endringer, og hvordan du slår sammen disse endringene og trekker forespørsler.

Men nå som du kjenner det grunnleggende, er det på tide å nivåere litt - for å dra nytte av noen av de kraftigere funksjonene til Git i arbeidsflyten din. Her er fem avanserte Git-funksjoner for å gjøre en del av din nåværende og fremtidige utviklingsinnsats.

Forenkle forpliktelseshistorikk med git rebase

Når du har to grener i et prosjekt (f.eks. En utviklingsgren og en hovedgren), som begge har endringer som må kombineres, git flette kommando er den naturlige og greie måten å forene dem på. EN slå sammen legger til utviklingshistorien til den ene grenen når en fusjon forplikter seg til den andre. Selv om dette bevarer begge historiene i detalj, kan det gjøre prosjektets samlede historie vanskelig å følge. I noen tilfeller vil du kanskje ha et enklere og renere resultat.

De git rebase kommando slår også sammen to grener, men gjør det litt annerledes. EN git rebase omskriver den ene grenens forpliktelseshistorie slik at den andre grenen blir innlemmet i den fra det punktet den ble opprettet. Dette gir en mindre støyende og mer lineær, begivenhetshistorie for den grenen. Men det betyr også at potensielt nyttige detaljer om den andre grenen og sammenslåingsprosessen fjernes.

Til den slutten, rebase brukes best når du har flere privat filialer du vil konsolidere i en enkelt, ren forpliktelseshistorikk før du slår den sammen med en offentlig filial. På denne måten får du full nytte avrebase - gjøre en forpliktelseshistorie mer lineær og mindre støyende - uten å skjule viktige detaljer om historien til forpliktelser til prosjektet ditt.

Rydding smelter sammen med git merge - squash

En annen måte å gjøre sammenslåinger, og påfølgende forpliktelser, mindre støyende er ved å bruke - squash alternativ i git flette. - squash tar alle forpliktelsene fra en innkommende gren og flater dem ut i en enkelt, konsolidert forpliktelse.

Det fine med en sammenpresset sammenslåing er at du kan velge hvordan du skal bruke de resulterende iscenesatte filene. Du kan bare utføre hele settet med endringer som en, eller du kan begå noen få filer om gangen der endringene er nært beslektede. En sammenpresset sammenslåing er også nyttig hvis begivenhetshistorikken til den innkommende grenen bare er nyttig i sammenheng med den grenen, eller hvis den kommer fra en privat gren som uansett skal kastes.

Som med en rebase, denne teknikken fungerer best for å begå innvendig grener å mestre, men det er også egnet for trekkforespørsler om nødvendig.

Fremskynde bugsøk med git bisect

Subtile regresjoner i kode er vanskeligst å erte. Tenk deg at du nettopp har lagt til en test i kodebasen for å jage ned en feil, men du er ikke sikker på når feilen først dukket opp ... og du har hundrevis eller til og med tusenvis av forpliktelser i depotet ditt. Degit bisect kommandoen lar deg redusere mengden kode du må søke for å finne forpliktelsen som skapte feilen.

Når du aktiverer halveres (git bisect start) du angir to punkter i kodebasen for å begrense søket: ett der du vet at ting er dårlige (HODE, vanligvis), og en der du vet at ting fortsatt var bra. halveres vil sjekke ut en forpliktelse halvveis mellom den dårlige forpliktelsen og den gode, og la deg kjøre testene dine. Denne binære inndelingsprosessen gjentas til den viser opp forpliktelsen som brøt ting.

git bisect er en gave for store kodebaser med lange, komplekse forpliktelseshistorier, og sparer deg for bryet med å måtte pote gjennom hver siste forpliktelse i håp om at du vil finne feilen din før eller senere. På veldig minst, det kutter ned med halve mengden søk og testing du trenger å gjøre.

På nytt forplikter seg med git cherry-pick

Mange avanserte git kommandoer er bare nyttige under snever spesifikke omstendigheter, og ignoreres trygt selv av moderat avanserte brukere. Men når du kjemper for en av disse spesifikke omstendighetene, lønner det seg å kjenne dem.

Ta i betraktning git cherry-pick. Det lar deg ta en gitt forpliktelse - hvilken som helst forpliktelse, fra hvilken som helst gren - og bruke den på en annen gren, uten å måtte bruke noen andre endringer fra historien til forpliktelsen. Dette er nyttig under noen få viktige omstendigheter:

  • Du forpliktet deg til feil gren, og du vil raskt bruke den på den rette.
  • Du vil bruke en løsning fra en gren til kofferten før du fortsetter med annet arbeid med koffertkode.

Vær oppmerksom på at du har noen alternativer i tillegg til direkte å bruke forpliktelsen når du kirsebærplukk den. Hvis du passerer - ikke forplikte alternativ, for eksempel, plasseres den kirsebærplukkede forpliktelsen i iscenesettelsesområdet til den nåværende grenen.

Organiser prosjekter elegant med Git-undermoduler

Akkurat som de fleste programmeringsspråk gir en måte å importere pakker eller moduler på, tilbyr Git en måte å automatisk inkludere innholdet i et lager i et annet, et submodul. Du kan opprette en underkatalog i en repo, og fylle den automatisk ut med innholdet i en annen repo, vanligvis ved å referere til en bestemt kommisjon-hash for å sikre konsistens.

Merk at Git-undermoduler fungerer best under følgende forhold:

  • De aktuelle delmodulene endres ikke ofte, eller de er låst til en bestemt forpliktelse. Alt arbeid en submodule, snarere enn med en undermodul, bør administreres separat.
  • Alle bruker en versjon av Git som støtter undermoduler og forstår trinnene som trengs for å jobbe med dem. For eksempel er undermodulkataloger ikke alltid fylt ut automatisk med innholdet i undermodulmagasinet. Du må kanskje bruke git submodule oppdatering kommando på repo for å bringe alt oppdatert.
$config[zx-auto] not found$config[zx-overlay] not found