Tilbakeføring av en Spesifikk Commit
git revert
Som vi allerede har nevnt, brukes kommandoen git revert for å tilbakestille en spesifikk commit. Denne kommandoen oppretter en ny commit som reverserer endringene introdusert av den angitte commiten. Grunnleggende syntaks er som følger:
git revert <commit-hash>
Som du ser, i stedet for å bruke HEAD slik vi gjorde for å tilbakestille den siste commiten, må vi nå spesifisere hashen til en bestemt commit (commit-ID) som vi ønsker å tilbakestille (erstatt <commit-hash> med en gyldig hash).
Mer om hasher
Husk at hver commit har sin unike ID, som i hovedsak er en streng av sifre (0-9) og bokstaver (a-f), altså en heksadesimal streng. Denne 40-tegns strengen kalles hash. La oss se på vår siste commit:
Her er dens hash:
1b00736255dca7d78659a9971d0c30fba0eb3075
Du vil ha en annen hash for denne commiten av grunnen som forklares nedenfor.
Commit-hashen beregnes ved hjelp av SHA-1-algoritmen basert på følgende informasjon:
- Commit-melding;
- Dato;
- Forfatter;
- Snapshot av arbeidsområdet;
- Hash for foreldrecommit (eller commits når det er mer enn én forelder).
Hvis commiten er den første i depotet, blir hash for foreldrecommit åpenbart ikke beregnet.
Siden all denne commit-informasjonen brukes til å beregne hashen, sikrer bruk av hasher som commit-IDer konsistensen i depotet. I tillegg er sannsynligheten for at to forskjellige commits har samme hash (sannsynligheten for kollisjon) ekstremt lav, så det er svært usannsynlig at det skjer ved en tilfeldighet.
I hovedsak, hvis noe endres i commiten, vil hashen også endre seg. Dette betyr at hvis dataene blir korrupte av en eller annen grunn, kan Git bruke hashen til å identifisere dette.
Når du endrer en commit, endres commit-ID-en, og derfor er det bedre å unngå å bruke kommandoen git commit --amend når du arbeider med eksterne (remote) repositorier.
Eksempel på arbeidsflyt
Før vi bestemmer oss for hvilken commit vi skal tilbakestille, la oss se på de fire siste commitene:
Vi ser at det finnes en commit hvor vi la til filen recipe.txt. La oss tilbakestille denne committen ved å opprette en ny commit som vil angre disse endringene og i praksis slette filen. I mitt tilfelle er hashen følgende:
043b634d76a7a7744757350512b6367417c29e0
Din hash for denne committen vil imidlertid være annerledes. Nå kan vi tilbakestille denne committen:
Erstatt denne hashen med din hash.
Igjen åpnes standard tekstredigerer med standard commit-melding for tilbakeføring. Vi lar den stå uendret.
Deretter lukker vi tekstredigereren på riktig måte og viser endringene som ble gjort i denne siste commiten:
7 slettinger fant sted, noe som betyr at alle 7 linjene i filen ble slettet. La oss nå verifisere at selve filen ble slettet ved å liste opp alle ikke-skjulte filer og kataloger i prosjektmappen vår:
Vi har slettet recipe.txt-filen.
Takk for tilbakemeldingene dine!
Spør AI
Spør AI
Spør om hva du vil, eller prøv ett av de foreslåtte spørsmålene for å starte chatten vår
Awesome!
Completion rate improved to 3.57Tilbakeføring av en Spesifikk Commit
Sveip for å vise menyen
git revert
Som vi allerede har nevnt, brukes kommandoen git revert for å tilbakestille en spesifikk commit. Denne kommandoen oppretter en ny commit som reverserer endringene introdusert av den angitte commiten. Grunnleggende syntaks er som følger:
git revert <commit-hash>
Som du ser, i stedet for å bruke HEAD slik vi gjorde for å tilbakestille den siste commiten, må vi nå spesifisere hashen til en bestemt commit (commit-ID) som vi ønsker å tilbakestille (erstatt <commit-hash> med en gyldig hash).
Mer om hasher
Husk at hver commit har sin unike ID, som i hovedsak er en streng av sifre (0-9) og bokstaver (a-f), altså en heksadesimal streng. Denne 40-tegns strengen kalles hash. La oss se på vår siste commit:
Her er dens hash:
1b00736255dca7d78659a9971d0c30fba0eb3075
Du vil ha en annen hash for denne commiten av grunnen som forklares nedenfor.
Commit-hashen beregnes ved hjelp av SHA-1-algoritmen basert på følgende informasjon:
- Commit-melding;
- Dato;
- Forfatter;
- Snapshot av arbeidsområdet;
- Hash for foreldrecommit (eller commits når det er mer enn én forelder).
Hvis commiten er den første i depotet, blir hash for foreldrecommit åpenbart ikke beregnet.
Siden all denne commit-informasjonen brukes til å beregne hashen, sikrer bruk av hasher som commit-IDer konsistensen i depotet. I tillegg er sannsynligheten for at to forskjellige commits har samme hash (sannsynligheten for kollisjon) ekstremt lav, så det er svært usannsynlig at det skjer ved en tilfeldighet.
I hovedsak, hvis noe endres i commiten, vil hashen også endre seg. Dette betyr at hvis dataene blir korrupte av en eller annen grunn, kan Git bruke hashen til å identifisere dette.
Når du endrer en commit, endres commit-ID-en, og derfor er det bedre å unngå å bruke kommandoen git commit --amend når du arbeider med eksterne (remote) repositorier.
Eksempel på arbeidsflyt
Før vi bestemmer oss for hvilken commit vi skal tilbakestille, la oss se på de fire siste commitene:
Vi ser at det finnes en commit hvor vi la til filen recipe.txt. La oss tilbakestille denne committen ved å opprette en ny commit som vil angre disse endringene og i praksis slette filen. I mitt tilfelle er hashen følgende:
043b634d76a7a7744757350512b6367417c29e0
Din hash for denne committen vil imidlertid være annerledes. Nå kan vi tilbakestille denne committen:
Erstatt denne hashen med din hash.
Igjen åpnes standard tekstredigerer med standard commit-melding for tilbakeføring. Vi lar den stå uendret.
Deretter lukker vi tekstredigereren på riktig måte og viser endringene som ble gjort i denne siste commiten:
7 slettinger fant sted, noe som betyr at alle 7 linjene i filen ble slettet. La oss nå verifisere at selve filen ble slettet ved å liste opp alle ikke-skjulte filer og kataloger i prosjektmappen vår:
Vi har slettet recipe.txt-filen.
Takk for tilbakemeldingene dine!
