En av de mest grunnleggende tjenestene som Git tilbyr, er prosjekthistorikken. Siden Git holder rede på alle endringer i filer som er gjort i et depot, kan det tilby svært kraftige loggfunksjoner. Du kan spørre prosjektets historie på mange forskjellige måter, og du kan trekke ut og vise forskjellige data ved hjelp av en fleksibel kommando.

De git logg kommandoen er enorm, den største av enhver vanlig Git-kommando. Håndboken er over 2500 linjer lang. Heldigvis, git logg gir mye av sin mest nyttige oppførsel fra bare noen få viktige alternativer.

Grunnleggende logging med standard atferd

Som standard, git logg viser en omvendt kronologisk liste over forpliktelser. Hver forpliktelse inneholder sin hash, forfatter, dato og forpliktelsesmelding:

Kommandoen bruker en personsøker (f.eks. Mindre, mer) for å vise hele utdataene, slik at du enkelt kan navigere i resultatene. Du kan konfigurere Git til å bruke et program du ønsker, for eksempel mest personsøker.

Her er noen git-loggutdata fra depotet til git-kildekoden seg selv:

instagram viewer
begå 670b81a890388c60b7032a4f5b879f2ece8c4558 (HEAD -> master, origin / next,
opprinnelse / master, opprinnelse / HEAD)
Forfatter: Junio ​​C Hamano
Dato: Man 14. juni 13:23:28 2021 +0900
Den andre batchen
Avskilt: Junio ​​C Hamano

Resultatet starter med kommisjonen hash (670...) etterfulgt av en liste over grener som for tiden peker på den forpliktelsen (HEAD -> master, etc.)

Neste linje beskriver forfatteren av denne forpliktelsen, med navn og e-postadresse.

Full dato og klokkeslett for forpliktelsen følger på neste linje.

Til slutt vises det fulle innholdet i forpliktelsesmeldingen. Du kan kontrollere det meste av alt annet som git log tilbyr med kommandolinjealternativer. Det er to hovedtyper av alternativer:

  • Formatering, som definerer hvordan Git viser hver kommisjon.
  • Filtrering, som definerer hvilken forpliktelse git logg inkluderer.

I tillegg til kommandolinjealternativer godtar git log argumenter som spesifiserer filer, forpliktelser, grener eller andre typer referanser. Disse bruker ytterligere filtrering.

Formatering av Git Log Output

En av de enkleste justeringene er --en linje alternativ som gir en veldig kort utgang:

git log --oneline

Hver linje i loggen inneholder nå bare en forkortet kommisjon hash og emnet for forpliktelsesmeldingen. Dette er en utmerket måte å få en oversikt over de siste forpliktelsene til prosjektet:

Dessverre, uten noen annen kontekst, er denne informasjonen ikke alltid så nyttig. Det kan gi deg en vag følelse av prosjektet, men det mangler datoer og annen nyttig informasjon om forfattere og filer.

Vise en grengraf

De --kurve alternativet lar deg visualisere forhold mellom grener. Det er veldig grunnleggende, men kan bidra til å løse en komplisert historie.

git log --oneline --graph

I slekt: Hvordan lage en ny gren i Git

Tilpasset Pretty Output

Du kan oppnå mer komplisert formatering ved å spesifisere den i detalj ved hjelp av --ganske alternativ. Syntaksen går fra veldig enkel til mye mer kompleks, så se en manual for komplette detaljer.

git log - ganske = kort

Er egentlig det samme som git logg uten dato eller full melding:

git-logg - ganske = online

Tilsvarer git log --oneline.

git log - ganske = fyldigere

Inkluderer mye detalj. Det skiller til og med forfatter og kommittør som i teorien kan være forskjellige mennesker:

Med format: variant, kan du levere en streng som inneholder hvilket innhold du vil, inkludert plassholdere som erstattes av forskjellige data. Her er noen eksempler på plassholdere:

  • % H begå hasj
  • % h forkortet begå hasj
  • % annonse forfatterdato
  • % ar forfatterdato, slektning
  • % s begå meldingsemne
  • % b begå melding kropp
  • % s forkortet foreldre hashes

Du kan legge til faste tegn i utgangen og fargelegge den. Dette eksemplet viser også en variant av datoformat:

git log --pretty = format: '% C (auto)% h [% ad]% s' --dato = kort

Merk at parenteser omgir datoen. Uansett hvilken formatering du velger, hvis du vil at utdataene skal være nyttige i en rørledning eller for andre former for tekstbehandling, bør du vurdere hvordan du kan avgrense hver del av utdataene.

Viser Diffs in the Log

En viktig detalj når vi ser på et forråds historie er forskjellene i seg selv. De representerer det som faktisk er endret i koden! For det første kan du få et sammendrag av endringene ved siden av hver forpliktelse ved hjelp --kortstat:

git log --shortstat

Dette legger til en linje som:

1 fil endret, 48 innsettinger (+), 2 slettinger (-)

Til bunnen av hver forpliktelse. Du vil ofte se denne typen sammendrag - for eksempel på sider på GitHub - og det er en nyttig måte å raskt vurdere omfanget av en bestemt forpliktelse. For mer detaljert informasjon, kan du inkludere full patch-utdata (diffs) ved hjelp av -p flagg:

git log -p

Filtrering av Git Log Output

Uansett hvilken formatering du bruker, vil du fremdeles se den fullstendige loggen over alle forpliktelser i den nåværende grenen. Selv om Git deler dem opp i sider, kan det fortsatt være mye produksjon. Følgende alternativer lar deg tilpasse hvilke forpliktelser loggen inneholder.

Begrensning etter beløp

Hvis du bare vil trimme resultatene for å vise de siste få forpliktelsene, bruker du -[Nummer] syntaks:

git log -2

Begrensning etter dato

For å begrense forpliktelsessettet til et gitt datoperiode, bruk --siden (--etter) og --før (--før) alternativer. Disse tar hver en dato i ISO 8601-format. Du kan bruke begge --siden eller --før alene, eller begge sammen for å spesifisere et område. Alternativene --etter og --før er synonymer.

git log --since = "2021-01-01" --until = "2021-05-01"

Begrensning etter fil

Git-loggen kan fokusere på en bestemt fil i stedet for hver fil i depotet ditt. Dette er bra for å hjelpe deg med å finne ut hvordan en bestemt fil har endret seg over tid. Bare legg til filnavnet til slutten av git-kommandoen:

git log filnavn

Du ser bare de forpliktelsene som berørte filnavn.

Forskjeller mellom grener

Du kan ha noen unike krav når du viser loggen til en gren. For eksempel, i stedet for å se hele historikken, vil du kanskje bare se hva som er endret i den spesifikke grenen. Git log kan hjelpe deg via ref1..ref2 syntaks. Det er tre litt forskjellige tilnærminger du kan bruke:

  1. Vis forpliktelser som er i hovedsak, men ikke gren:
    git log --online origin / branch..origin / main
  2. Se forpliktelser som er i gren, men ikke hoved:
    git log --online opprinnelse /hoved-..opprinnelse/gren
  3. Vis forpliktelser som bare eksisterer i gren eller hoved:
    git log --online opprinnelse / gren...opprinnelse / hoved

Akkurat som du kan se historikk mellom grener ved hjelp av ref1..ref2 syntaks, kan du også se historikk mellom tagger på samme måte. Tross alt er både koder og grener referansetyper.

git log --abbrev-commit --pretty = format: '% h% ar% s' v2.32.0-rc3..v2.32.0

Hvis du forbereder utgivelsesmerknader for et større prosjekt, git shortlog skal være din første anløpshavn. Den produserer en liste over forfattere med forpliktende emner ved siden av seg. Du kan sende det et referanseområde for å begrense historikken på en lignende måte som git log:

git shortlog v2.32.0-rc3..v2.32.0

De git show-kommando er enda mer allsidig enn git logg. Det kan fungere med koder og andre typer git-objekter utover begivenhetshistorien. Den deler mange opsjoner med git logg, men du trenger det bare hvis du trenger å grave ned i detaljer på lavere nivå.

Gjennomgå fortiden med Git-loggen

Git-logg er en komplisert kommando, men du kan få mye bruk av de mest grunnleggende alternativene. Å bla gjennom historikken til et depot er en utmerket måte å forstå hvor ofte endringer skjer og hvor mange som gjør dem. Når du har god forståelse for prosjektets historie, vil du være i en god posisjon til å bidra til det selv.

E-post
Bli med på den sosiale kodingstrenden og bidra til GitHub Repositories

Vil du trene dine kodende muskler og hjelpe åpen kildekode-prosjekter? Slik bidrar du til GitHub.

Les Neste

Relaterte temaer
  • Programmering
  • GitHub
  • Kodingstips
Om forfatteren
Bobby Jack (54 artikler publisert)

Bobby er en teknologientusiast som jobbet som programvareutvikler i det meste av to tiår. Han brenner for spill, jobber som Reviews Editor i Switch Player Magazine, og er fordypet i alle aspekter av online publisering og nettutvikling.

Mer fra Bobby Jack

Abonner på vårt nyhetsbrev

Bli med på nyhetsbrevet vårt for tekniske tips, anmeldelser, gratis e-bøker og eksklusive tilbud!

Ett steg til…!

Bekreft e-postadressen din i e-posten vi nettopp sendte deg.

.