Chapters ▾ 2nd Edition

7.1 Git Tools - Hersieningseleksie (Revision Selection)

By now, you’ve learned most of the day-to-day commands and workflows that you need to manage or maintain a Git repository for your source code control. You’ve accomplished the basic tasks of tracking and committing files, and you’ve harnessed the power of the staging area and lightweight topic branching and merging.

Now you’ll explore a number of very powerful things that Git can do that you may not necessarily use on a day-to-day basis but that you may need at some point.

Hersieningseleksie (Revision Selection)

Git laat jou toe om op 'n aantal maniere na 'n enkele vaslegging (commit), 'n stel vasleggings, of 'n reeks vasleggings te verwys. Hulle is nie noodwendig voor die hand liggend nie, maar dit is nuttig om dit te weet.

Enkel Hersienings (Single Revisions)

Jy kan natuurlik na enige enkele vaslegging verwys deur sy volle, 40-karakter SHA-1 huts (hash), maar daar is ook meer mensvriendelike maniere om na vasleggings te verwys. Hierdie afdeling skets die verskillende maniere waarop jy na enige vaslegging kan verwys.

Kort SHA-1 (Short SHA-1)

Git is slim genoeg om uit te vind na watter vaslegging jy verwys as jy die eerste paar karakters van die SHA-1 huts verskaf, solank daardie gedeeltelike huts ten minste vier karakters lank is en ondubbelsinnig is; dit wil sê, geen ander objek in die objekdatabasis kan 'n huts hê wat met dieselfde voorvoegsel (prefix) begin nie.

Byvoorbeeld, om 'n spesifieke vaslegging te ondersoek waar jy weet dat jy sekere funksionaliteit bygevoeg het, kan jy eers die git log opdrag uitvoer om die vaslegging op te spoor:

$ git log
commit 734713bc047d87bf7eac9674765ae793478c50d3
Author: Scott Chacon <schacon@gmail.com>
Date:   Fri Jan 2 18:32:33 2009 -0800

    Fix refs handling, add gc auto, update tests

commit d921970aadf03b3cf0e71becdaab3147ba71cdef
Merge: 1c002dd... 35cfb2b...
Author: Scott Chacon <schacon@gmail.com>
Date:   Thu Dec 11 15:08:43 2008 -0800

    Merge commit 'phedders/rdocs'

commit 1c002dd4b536e7479fe34593e72e6c6c1819e53b
Author: Scott Chacon <schacon@gmail.com>
Date:   Thu Dec 11 14:58:32 2008 -0800

    Add some blame and merge stuff

In hierdie geval, sê nou jy stel belang in die vaslegging waarvan die huts met 1c002dd…​ begin. Jy kan daardie vaslegging met enige van die volgende variasies van git show ondersoek (aannemende die korter weergawes is ondubbelsinnig):

$ git show 1c002dd4b536e7479fe34593e72e6c6c1819e53b
$ git show 1c002dd4b536e7479f
$ git show 1c002d

Git kan 'n kort, unieke afkorting vir jou SHA-1 waardes uitwerk. As jy --abbrev-commit na die git log opdrag aangee, sal die afvoer korter waardes gebruik maar dit uniek hou; dit gebruik by verstek sewe karakters maar maak dit langer indien nodig om die SHA-1 ondubbelsinnig te hou:

$ git log --abbrev-commit --pretty=oneline
ca82a6d Change the version number
085bb3b Remove unnecessary test code
a11bef0 Initial commit

Oor die algemeen is agt tot tien karakters meer as genoeg om uniek binne 'n projek te wees. Byvoorbeeld, soos in Februarie 2019, het die Linux-kern (wat 'n redelike groot projek is) meer as 875 000 vasleggings en byna sewe miljoen objekte in sy objekdatabasis, met geen twee objekte waarvan die SHA-1’s in die eerste 12 karakters identies is nie.

Note
'N KORT NOTA OOR SHA-1

Baie mense raak op een of ander stadium bekommerd dat hulle, deur blote toeval, twee afsonderlike objekte in hul bewaarplek sal hê wat na dieselfde SHA-1 waarde huts. Wat dan?

As jy toevallig 'n objek vaslê wat na dieselfde SHA-1 waarde as 'n vorige verskillende objek in jou bewaarplek huts, sal Git die vorige objek wat reeds in jou Git-databasis is sien, aanneem dit was reeds geskryf en dit eenvoudig hergebruik. As jy daardie objek op 'n stadium weer probeer uittrek (check out), sal jy altyd die data van die eerste objek kry.

Jy moet egter bewus wees van hoe belaglik onwaarskynlik hierdie scenario is. Die SHA-1 opsomming (digest) is 20 grepe of 160 bisse. Die aantal ewekansig gehutste objekte wat nodig is om 'n 50% waarskynlikheid van 'n enkele botsing te verseker, is ongeveer 280 (die formule vir die bepaling van botsingswaarskynlikheid is p = (n(n-1)/2) * (1/2^160)). 280 is 1.2 x 1024 of 1 miljoen miljard miljard. Dit is 1 200 keer die aantal sandkorrels op die aarde.

Hier is 'n voorbeeld om jou 'n idee te gee van wat dit sal neem om 'n SHA-1 botsing te kry. As al 6.5 miljard mense op aarde geprogrammeer het, en elke sekonde was elkeen besig om kode te produseer wat die ekwivalent was van die hele Linux-kern geskiedenis (6.5 miljoen Git objekte) en dit in een enorme Git bewaarplek in te push, sal dit ongeveer 2 jaar neem totdat daardie bewaarplek genoeg objekte bevat om 'n 50% waarskynlikheid van 'n enkele SHA-1 objek botsing te hê. 'n Organiese SHA-1 botsing is dus minder waarskynlik as dat elke lid van jou programmeringspan op dieselfde aand in onverwante voorvalle deur wolwe aangeval en vermoor word.

As jy rekenaarkrag ter waarde van duisende rande daaraan wy, is dit moontlik om twee lêers met dieselfde huts te sintetiseer, soos in Februarie 2017 op https://shattered.io/ bewys is. Git beweeg daarna om SHA256 as die verstek huts-algoritme te gebruik, wat baie meer veerkragtig teen botsingsaanvalle is, en het kode in plek om hierdie aanval te help versag (hoewel dit nie heeltemal uitgeskakel kan word nie).

Takverwysings (Branch References)

Een eenvoudige manier om na 'n spesifieke vaslegging te verwys is as dit die vaslegging aan die punt van 'n tak is; in daardie geval kan jy eenvoudig die taknaam gebruik in enige Git-opdrag wat 'n verwysing na 'n vaslegging verwag. Byvoorbeeld, as jy die laaste vasleggingsobjek op 'n tak wil ondersoek, is die volgende opdragte ekwivalent, in die veronderstelling dat die topic1 tak na die vaslegging ca82a6d…​ wys:

$ git show ca82a6dff817ec66f44342007202690a93763949
$ git show topic1

As jy wil sien na watter spesifieke SHA-1 'n tak wys, of as jy wil sien waarop enige van hierdie voorbeelde neerkom in terme van SHA-1’s, kan jy 'n Git loodgietersinstrument (plumbing tool) genaamd rev-parse gebruik. Jy kan Git Internals bekyk vir meer inligting oor loodgietersinstrumente; basies, rev-parse bestaan vir laervlak bedrywighede en is nie ontwerp om in dag-tot-dag bedrywighede gebruik te word nie. Dit kan egter soms nuttig wees wanneer jy moet sien wat werklik aangaan. Hier kan jy rev-parse op jou tak uitvoer.

$ git rev-parse topic1
ca82a6dff817ec66f44342007202690a93763949

RefLog Kortname (RefLog Shortnames)

Een van die dinge wat Git in die agtergrond doen terwyl jy werk, is om 'n “reflog” te hou — 'n logboek van waar jou HEAD en takverwysings die afgelope paar maande was.

Jy kan jou reflog sien deur git reflog te gebruik:

$ git reflog
734713b HEAD@{0}: commit: Fix refs handling, add gc auto, update tests
d921970 HEAD@{1}: merge phedders/rdocs: Merge made by the 'recursive' strategy.
1c002dd HEAD@{2}: commit: Add some blame and merge stuff
1c36188 HEAD@{3}: rebase -i (squash): updating HEAD
95df984 HEAD@{4}: commit: # This is a combination of two commits.
1c36188 HEAD@{5}: rebase -i (squash): updating HEAD
7e05da5 HEAD@{6}: rebase -i (pick): updating HEAD

Elke keer as jou takpunt vir enige rede bygewerk word, stoor Git daardie inligting vir jou in hierdie tydelike geskiedenis. Jy kan jou reflog data gebruik om na ouer vasleggings ook te verwys. Byvoorbeeld, as jy die vyfde vorige waarde van die HEAD van jou bewaarplek wil sien, kan jy die @{5} verwysing gebruik wat jy in die reflog-afvoer sien:

$ git show HEAD@{5}

Jy kan ook hierdie sintaksis gebruik om te sien waar 'n tak 'n sekere spesifieke tyd gelede was. Byvoorbeeld, om te sien waar jou master tak gister was, kan jy tik:

$ git show master@{yesterday}

Dit sal vir jou wys waar die punt van jou master tak gister was. Hierdie tegniek werk slegs vir data wat steeds in jou reflog is, so jy kan dit nie gebruik om vir vasleggings te soek wat ouer as 'n paar maande is nie.

Om reflog-inligting te sien wat soos die git log-afvoer geformateer is, kan jy git log -g uitvoer:

$ git log -g master
commit 734713bc047d87bf7eac9674765ae793478c50d3
Reflog: master@{0} (Scott Chacon <schacon@gmail.com>)
Reflog message: commit: Fix refs handling, add gc auto, update tests
Author: Scott Chacon <schacon@gmail.com>
Date:   Fri Jan 2 18:32:33 2009 -0800

    Fix refs handling, add gc auto, update tests

commit d921970aadf03b3cf0e71becdaab3147ba71cdef
Reflog: master@{1} (Scott Chacon <schacon@gmail.com>)
Reflog message: merge phedders/rdocs: Merge made by recursive.
Author: Scott Chacon <schacon@gmail.com>
Date:   Thu Dec 11 15:08:43 2008 -0800

    Merge commit 'phedders/rdocs'

Dit is belangrik om daarop te let dat reflog-inligting streng plaaslik is — dit is slegs 'n log van wat jy in jou bewaarplek gedoen het. Die verwysings sal nie dieselfde wees op iemand anders se kopie van die bewaarplek nie; ook, net nadat jy aanvanklik 'n bewaarplek gekloon het, sal jy 'n leë reflog hê, aangesien geen aktiwiteit nog in jou bewaarplek plaasgevind het nie. Deur git show HEAD@{2.months.ago} uit te voer, sal dit net die ooreenstemmende vaslegging wys as jy die projek ten minste twee maande gelede gekloon het — as jy dit enigsins meer onlangs as dit gekloon het, sal jy slegs jou eerste plaaslike vaslegging sien.

Tip
Dink aan die reflog as Git se weergawe van dop-geskiedenis (shell history)

As jy 'n UNIX of Linux agtergrond het, kan jy aan die reflog dink as Git se weergawe van dop-geskiedenis, wat beklemtoon dat wat daar is, duidelik net vir jou en jou “sessie” relevant is, en niks te doen het met enigiemand anders wat dalk op dieselfde masjien werk nie.
Note
Die ontsnapping van krulhakies in PowerShell

Wanneer jy PowerShell gebruik, is krulhakies soos { en } spesiale karakters en moet dit ontsnap word. Jy kan hulle ontsnap met 'n truteken (backtick) ` of die vasleggingsverwysing in aanhalingstekens plaas:

$ git show HEAD@{0}     # sal NIE werk nie
$ git show HEAD@`{0`}   # OK
$ git show "HEAD@{0}"   # OK

Voorouer Verwysings (Ancestry References)

Die ander hoofmanier om 'n vaslegging te spesifiseer, is via sy voorouerskap. As jy 'n ^ (kappie/caret) aan die einde van 'n verwysing plaas, beskou Git dit as die ouer van daardie vaslegging. Gestel jy kyk na die geskiedenis van jou projek:

$ git log --pretty=format:'%h %s' --graph
* 734713b Fix refs handling, add gc auto, update tests
*   d921970 Merge commit 'phedders/rdocs'
|\
| * 35cfb2b Some rdoc changes
* | 1c002dd Add some blame and merge stuff
|/
* 1c36188 Ignore *.gem
* 9b29157 Add open3_detach to gemspec file list

Dan kan jy die vorige vaslegging sien deur HEAD^ te spesifiseer, wat “die ouer van HEAD” beteken:

$ git show HEAD^
commit d921970aadf03b3cf0e71becdaab3147ba71cdef
Merge: 1c002dd... 35cfb2b...
Author: Scott Chacon <schacon@gmail.com>
Date:   Thu Dec 11 15:08:43 2008 -0800

    Merge commit 'phedders/rdocs'
Note
Die ontsnapping van die kappie op Windows

Op Windows in cmd.exe is ^ 'n spesiale karakter en moet dit anders behandel word. Jy kan dit of verdubbel of die vasleggingsverwysing in aanhalingstekens plaas:

$ git show HEAD^     # sal NIE werk op Windows nie
$ git show HEAD^^    # OK
$ git show "HEAD^"   # OK

Jy kan ook 'n nommer na die ^ spesifiseer om te identifiseer watter ouer jy wil hê; byvoorbeeld, d921970^2 beteken “die tweede ouer van d921970.” Hierdie sintaksis is slegs nuttig vir saamsmeltingsvasleggings (merge commits), wat meer as een ouer het — die eerste ouer van 'n saamsmeltingsvaslegging is vanaf die tak waarop jy was toe jy saamgesmelt het (dikwels master), terwyl die tweede ouer van 'n saamsmeltingsvaslegging vanaf die tak is wat ingesmelt is (sê nou, topic):

$ git show d921970^
commit 1c002dd4b536e7479fe34593e72e6c6c1819e53b
Author: Scott Chacon <schacon@gmail.com>
Date:   Thu Dec 11 14:58:32 2008 -0800

    Add some blame and merge stuff

$ git show d921970^2
commit 35cfb2b795a55793d7cc56a6cc2060b4bb732548
Author: Paul Hedderly <paul+git@mjr.org>
Date:   Wed Dec 10 22:22:03 2008 +0000

    Some rdoc changes

Die ander belangrike voorouerspesifikasie is die ~ (tilde). Dit verwys ook na die eerste ouer, dus HEAD~ en HEAD^ is ekwivalent. Die verskil word duidelik wanneer jy 'n nommer spesifiseer. HEAD~2 beteken “die eerste ouer van die eerste ouer,” of “die grootouer” — dit loop deur die eerste ouers vir die aantal kere wat jy spesifiseer. Byvoorbeeld, in die geskiedenis wat vroeër gelys is, sou HEAD~3 wees:

$ git show HEAD~3
commit 1c3618887afb5fbcbea25b7c013f4e2114448b8d
Author: Tom Preston-Werner <tom@mojombo.com>
Date:   Fri Nov 7 13:47:59 2008 -0500

    Ignore *.gem

Dit kan ook as HEAD~~~ geskryf word, wat weereens die eerste ouer van die eerste ouer van die eerste ouer is:

$ git show HEAD~~~
commit 1c3618887afb5fbcbea25b7c013f4e2114448b8d
Author: Tom Preston-Werner <tom@mojombo.com>
Date:   Fri Nov 7 13:47:59 2008 -0500

    Ignore *.gem

Jy kan ook hierdie sintaksisse kombineer — jy kan die tweede ouer van die vorige verwysing kry (aannemende dat dit 'n saamsmeltingsvaslegging was) deur HEAD~3^2 te gebruik, ensovoorts.

Vasleggingsreekse (Commit Ranges)

Noudat jy individuele vasleggings kan spesifiseer, kom ons kyk hoe om reekse van vasleggings te spesifiseer. Dit is veral nuttig vir die bestuur van jou takke — as jy baie takke het, kan jy reekspesifikasies gebruik om vrae te beantwoord soos: “Watter werk is op hierdie tak wat ek nog nie in my hooftak ingesmelt het nie?”

Dubbelpunt (Double Dot)

Die mees algemene reeks-spesifikasie is die dubbelpunt-sintaksis. Dit vra basies vir Git om 'n reeks vasleggings op te los wat vanaf een vaslegging bereikbaar is, maar nie vanaf 'n ander bereikbaar is nie. Sê byvoorbeeld jy het 'n vasleggingsgeskiedenis wat soos Voorbeeldgeskiedenis vir reeksseleksie lyk.

Example history for range selection
Figure 149. Voorbeeldgeskiedenis vir reeksseleksie

Sê jy wil sien wat in jou experiment tak is wat nog nie in jou master tak ingesmelt is nie. Jy kan Git vra om vir jou 'n logboek te wys van net daardie vasleggings met master..experiment — dit beteken “alle vasleggings bereikbaar vanaf experiment wat nie bereikbaar is vanaf master nie.” Ter wille van beknoptheid en duidelikheid in hierdie voorbeelde, word die letters van die vasleggingsobjekte uit die diagram in die plek van die werklike log-afvoer gebruik in die volgorde wat dit sal vertoon:

$ git log master..experiment
D
C

As jy, aan die ander kant, die teenoorgestelde wil sien — alle vasleggings in master wat nie in experiment is nie — kan jy die takname omruil. experiment..master wys vir jou alles in master wat nie bereikbaar is vanaf experiment nie:

$ git log experiment..master
F
E

Dit is nuttig as jy die experiment tak op datum wil hou en 'n voorskou wil kry van wat jy op die punt is om in te smelt. Nog 'n algemene gebruik van hierdie sintaksis is om te sien wat jy op die punt is om na 'n remote te push:

$ git log origin/master..HEAD

Hierdie opdrag wys vir jou enige vasleggings in jou huidige tak wat nie in die master tak op jou origin remote is nie. As jy 'n git push uitvoer en jou huidige tak spoor (tracks) origin/master na, is die vasleggings wat deur git log origin/master..HEAD gelys word, die vasleggings wat na die bediener oorgedra sal word. Jy kan ook een kant van die sintaksis weglaat om Git te laat aanneem HEAD word bedoel. Byvoorbeeld, jy kan dieselfde resultate as in die vorige voorbeeld kry deur git log origin/master.. te tik — Git vervang HEAD as die een kant ontbreek.

Veelvuldige Punte (Multiple Points)

Die dubbelpunt-sintaksis is nuttig as 'n kortpad, maar miskien wil jy meer as twee takke spesifiseer om jou hersiening aan te dui, soos om te sien watter vasleggings in enige van verskeie takke is wat nie in die tak is waarop jy tans is nie. Git laat jou toe om dit te doen deur óf die ^ karakter óf --not te gebruik voor enige verwysing waarvan jy nie bereikbare vasleggings wil sien nie. Die volgende drie opdragte is dus ekwivalent:

$ git log refA..refB
$ git log ^refA refB
$ git log refB --not refA

Dit is handig want met hierdie sintaksis kan jy meer as twee verwysings in jou navraag spesifiseer, wat jy nie met die dubbelpunt-sintaksis kan doen nie. Byvoorbeeld, as jy alle vasleggings wil sien wat vanaf refA of refB bereikbaar is, maar nie vanaf refC nie, kan jy enige van die volgende gebruik:

$ git log refA refB ^refC
$ git log refA refB --not refC

Dit sorg vir 'n baie kragtige hersieningsnavraagstelsel wat jou behoort te help om uit te vind wat in jou takke is.

Driedubbelpunt (Triple Dot)

Die laaste belangrike reeks-seleksie sintaksis is die driedubbelpunt-sintaksis, wat al die vasleggings spesifiseer wat bereikbaar is deur enigeen van twee verwysings, maar nie deur albei van hulle nie. Kyk terug na die voorbeeld vasleggingsgeskiedenis in Voorbeeldgeskiedenis vir reeksseleksie. As jy wil sien wat in master of experiment is, maar nie enige algemene verwysings nie, kan jy uitvoer:

$ git log master...experiment
F
E
D
C

Weereens, dit gee jou normale log afvoer maar wys jou net die vasleggingsinligting vir daardie vier vasleggings, wat in die tradisionele vasleggingsdatumvolgorde verskyn.

'n Algemene skakelaar (switch) om in hierdie geval met die log opdrag te gebruik is --left-right, wat jou wys aan watter kant van die reeks elke vaslegging is. Dit help om die afvoer nuttiger te maak:

$ git log --left-right master...experiment
< F
< E
> D
> C

Met hierdie gereedskap kan jy Git baie makliker laat weet watter vaslegging of vasleggings jy wil inspekteer.