Skozi knjigo smo predstavili na desetine ukazov Git in se trudili, da bi jih predstavili znotraj neke vrste pripovedi s postopnim dodajanjem več ukazov v zgodbo. Vendar pa to pusti primere uporabe ukazov nekoliko razpršene po celotni knjigi.
V tem dodatku bomo pregledali vse ukaze Git, ki smo jih obravnavali v knjigi, in približno so razvrščeni glede na to, za kaj se uporabljajo. Govorili bomo o tem, kaj vsak ukaz na splošno naredi, in nato poudarili, kje v knjigi smo ga uporabili.
Tip
|
Dolge možnosti lahko skrajšate.
Na primer, vtipkate lahko |
Obstajata dva ukaza, ki se precej pogosto uporabljata od prve uporabe Gita do skupnega vsakodnevnega prilagajanja in sklicevanja: ukaza config
in help
.
Git ima privzeti način za izvajanje na stotine stvari. Za veliko teh stvari lahko Gitu poveste, naj jih privzeto izvaja drugače, ali pa nastavite svoje preference. To vključuje vse, od tega, da poveste Gitu, kako vam je ime, do določenih nastavitev barv terminala, ali pa kateri urejevalnik uporabljate. Obstaja več datotek, ki jih bo ta ukaz prebral in zapisal, tako da lahko vrednosti nastavite globalno ali na specifičnih repozitorijih.
Ukaz git config
se uporablja v skoraj vsakem poglavju knjige.
V razdelku ch01-getting-started.asc smo ga uporabili, da smo pred začetkom uporabe Gita določili svoje ime, e-poštni naslov in nastavitve urejevalnika.
V razdelku ch02-git-basics-chapter.asc smo pokazali, kako ga lahko uporabite za ustvarjanje okrajšanih ukazov, ki se razširijo v dolge zaporedne možnosti, da jih ni treba vsakič vpisovati.
V razdelku ch03-git-branching.asc smo ga uporabili, da smo določili privzeto vedenje --rebase
, ko zaženemo ukaz git pull
.
V razdelku ch07-git-tools.asc smo ga uporabili, da smo nastavili privzeti repozitorij za vaša gesla HTTP.
V razdelku ch08-customizing-git.asc smo pokazali, kako nastaviti t. i. filtra smudge
in clean
na vsebini, ki prihaja in odhaja iz Gita.
Nazadnje, skoraj celoten razdelek ch08-customizing-git.asc je posvečen temu ukazu.
Poleg navodil za nastavitve konfiguracije v razdelku ch01-getting-started.asc, se lahko mnogi urejevalniki nastavijo na naslednji način:
core.editor
Urejevalnik | Konfiguracijski ukaz |
---|---|
Atom |
|
BBEdit (macOS, with command line tools) |
|
Emacs |
|
Gedit (Linux) |
|
Gvim (Windows 64-bit) |
|
Helix |
|
Kate (Linux) |
|
nano |
|
Notepad (Windows 64-bit) |
|
Notepad++ (Windows 64-bit) |
|
Scratch (Linux) |
|
Sublime Text (macOS) |
|
Sublime Text (Windows 64-bit) |
|
TextEdit (macOS) |
|
Textmate |
|
Textpad (Windows 64-bit) |
|
UltraEdit (Windows 64-bit) |
|
Vim |
|
Visual Studio Code |
|
VSCodium (Free/Libre Open Source Software Binaries of VSCode) |
|
WordPad |
|
Xi |
|
Note
|
Če imate na 64-bitnem sistemu Windows 32-bitni urejevalnik, bo program nameščen v |
Ukaz git help
se uporablja za prikaz dokumentacije katerega koli ukaza, ki ga Git vsebuje.
Čeprav smo v tem dodatku podali grob pregled večine najbolj priljubljenih ukazov, lahko vedno za celoten seznam vseh možnih možnosti in zastavic vsakega ukaza zaženete git help <ukaz>
.
Ukaz git help
smo predstavili v razdelku ch01-getting-started.asc in prikazali, kako ga uporabiti za iskanje dodatnih informacij o git shell
v razdelku ch04-git-on-the-server.asc.
Obstajata dva načina za pridobivanje repozitorijev Git. Eden je kopiranje iz obstoječega repozitorija v omrežju ali drugje, druga pa je ustvarjanje novega v obstoječem direktoriju.
Da bi iz direktorija ustvarili nov repozitorij Git in začeli uporabljati nadzor različic, preprosto zaženite git init
.
To smo najprej predstavili v razdelku ch02-git-basics-chapter.asc, kjer smo ustvarili popolnoma nov repozitorij, s katerim smo začeli delati.
V razdelku ch03-git-branching.asc smo na kratko govorili o tem, kako lahko spremenite privzeto ime veje »master«.
Ta ukaz smo uporabili za ustvarjanje praznega golega repozitorija za strežnik v ch04-git-on-the-server.asc.
Nazadnje pa smo v ch10-git-internals.asc podrobno razložili, kaj ukaz dejansko počne za zavesami.
Ukaz git clone
je dejansko nekakšen ovitek okoli več drugih ukazov.
Ustvari novo mapo, vstopi vanjo in zažene git init
, da naredi prazen repozitorij Git, doda oddaljeni strežnik (git remote add
) na naslov URL, ki se mu ga poda (privzeto poimenovan origin
), zažene git fetch
iz tega oddaljenega repozitorija in nato z git checkout
izvleče najnovejšo potrditev v vaši delovni mapi.
Ukaz git clone
se uporablja na desetinah mest po knjigi, vendar bomo našteli le nekaj zanimivih.
Osnovno je predstavljen in pojasnjen v ch02-git-basics-chapter.asc, kjer smo predstavili nekaj primerov.
V razdelku ch04-git-on-the-server.asc smo preučili uporabo možnosti --bare
, da ustvarimo kopijo repozitorija Git brez delovne mape.
V razdelku ch07-git-tools.asc smo ga uporabili za odprtje repozitorija Git, povezanega v paket.
Končno pa smo v razdelku ch07-git-tools.asc spoznali možnost --recurse-submodules
, ki poenostavi kloniranje repozitorija z vdelanimi podmoduli.
Čeprav se uporablja na mnogih drugih mestih v knjigi, so ta tista, ki so nekoliko edinstvena, ali kjer se uporablja na načine, ki se nekoliko razlikujejo.
Za osnovni potek dela s posnetki vsebine in potrjevanjem v zgodovino je le nekaj osnovnih ukazov.
Ukaz git add
doda vsebino iz delovnega direktorija v področje priprave podatkov (ali »indeks«) za naslednjo potrditev.
Ko se zažene ukaz git commit
, privzeto pogleda le to področje za pripravo, zato se ukaz git add
uporablja za urejanje, kaj želite imeti v naslednjem posnetku potrditve.
Ta ukaz je v Gitu izjemno pomemben in je v tej knjigi omenjen ali uporabljen na desetine mest. Hitro bomo pokrili nekatere edinstvene načine uporabe.
Najprej smo podrobno predstavili in razložili git add
v razdelku ch02-git-basics-chapter.asc.
V razdelku ch03-git-branching.asc smo omenili, kako ga uporabiti za reševanje konfliktov združevanja.
V razdelku ch07-git-tools.asc smo prešli na uporabo interaktivnega področja za pripravo samo določenih delov spremenjene datoteke.
Končno smo ga v razdelku ch10-git-internals.asc emulirali na nizki ravni, tako da lahko dobite idejo, kaj počne za zavesami.
Ukaz git status
vam bo pokazal različna stanja datotek v vašem delovnem direktoriju in področju priprave.
Katere datoteke so spremenjene in niso v področju priprave ter katere so v področju priprave, vendar še niso bile potrjene.
V svoji običajni obliki vam bo tudi pokazal nekaj osnovnih namigov, kako premikati datoteke med temi stopnjami.
Najprej smo obravnavali status
v razdelku ch02-git-basics-chapter.asc, tako v svojih osnovnih kot poenostavljenih oblikah.
Čeprav ga uporabljamo skozi celotno knjigo, je tam zajeto praktično vse, kar lahko storite z ukazom git status
.
Ukaz git diff
se uporablja, ko želite videti razlike med katerima koli dvema drevesoma.
To bi lahko bila razlika med vašim delovnim okoljem in področjem priprave (git diff
sam po sebi), med področjem priprave in zadnjim potrjenim stanjem (git diff --staged
) ali med dvema potrjenima stanjema (git diff master branchB
).
Najprej smo si ogledali osnovne uporabe ukaza git diff
v razdelku ch02-git-basics-chapter.asc, kjer smo prikazali, kako si ogledati, katere spremembe so pripravljene in katere še niso.
Uporabili smo ga za iskanje morebitnih težav s praznimi znaki pred potrditvijo z možnostjo --check
v razdelku ch05-distributed-git.asc.
V razdelku ch05-distributed-git.asc smo prikazali, kako preveriti razlike med vejami bolj učinkovito s sintakso git diff A…B
.
V razdelku ch07-git-tools.asc smo ga uporabili za filtriranje razlik med praznimi znaki z -b
in primerjavo različnih stopenj konfliktnih datotek z --theirs
, --ours
in --base
.
Nazadnje smo ga uporabili v razdelku ch07-git-tools.asc za učinkovito primerjavo sprememb podmodulov z možnostjo --submodule
.
Ukaz git difftool
preprosto zažene zunanje orodje, ki vam prikaže razliko med dvema drevesoma, v primeru, da želite uporabiti kaj drugega kot le vgrajeni git diff
ukaz.
To smo omenili le na kratko v ch02-git-basics-chapter.asc.
Ukaz git commit
vzame vsebino datotek, ki so bile dane v pripravo z git add
in zabeleži nov trajni posnetek v bazi podatkov in nato premakne kazalec veje na trenutni veji.
Osnove za izvajanje posnetkov smo predstavili v ch02-git-basics-chapter.asc.
Tam smo prikazali tudi, kako uporabiti zastavico -a
, da preskočite korak git add
v vsakodnevnih potekih dela in kako uporabiti zastavico -m
, da v ukazni vrstici predate sporočilo za potrditev namesto zagona urejevalnika.
V razdelku ch02-git-basics-chapter.asc smo predstavili uporabo možnosti --amend
, s katero lahko ponovno opravite zadnjo potrditev.
V razdelku ch03-git-branching.asc smo šli v podrobnosti, kaj git commit
naredi in zakaj to počne na ta način.
V razdelku ch07-git-tools.asc smo pogledali kako kriptografsko podpisati posnetke z zastavico -S
.
Nazadnje smo v razdelku ch10-git-internals.asc pogledali, kaj ukaz git commit
naredi v ozadju in kako je dejansko izveden.
Ukaz git reset
se uporablja predvsem za razveljavitev stvari, kot se morda lahko sklepa iz glagola.
Kazalec HEAD
premakne in po potrebi spremeni kazalec index
ali področje priprave in poleg tega lahko z možnostjo --hard
po potrebi spremeni delovni imenik.
S to končno možnostjo je mogoče izgubiti delo, če se uporabi napačno, zato se prepričajte, da ga razumete, preden ga uporabite.
Najprej smo obravnavali najpreprostejšo uporabo ukaza git reset
v razdelku ch02-git-basics-chapter.asc, kjer smo ga uporabili za razveljavitev priprave datoteke, na kateri smo že uporabili ukaz git add
.
Podrobno smo ga obravnavali v razdelku ch07-git-tools.asc, ki je v celoti posvečeno razlagi tega ukaza.
Ukaz git reset --hard
smo uporabili za preklic združevanja v razdelku ch07-git-tools.asc, kjer smo uporabili tudi ukaz git merge --abort
, ki je nekakšen ovoj za ukaz git reset
.
Ukaz git rm
se uporablja za odstranjevanje datotek iz področja priprave in delovnega direktorija Git.
Podobno kot ukaz git add
, tudi ta ukaz pripravi odstranitev datoteke za naslednjo potrditev.
V razdelku ch02-git-basics-chapter.asc smo podrobneje obravnavali ukaz git rm
, vključno z rekurzivnim odstranjevanjem datotek in odstranjevanjem datotek samo iz področja priprave, vendar jih pustimo v delovnem direktoriju z uporabo možnosti --cached
.
Edina druga različna uporaba ukaza git rm
v knjigi je v razdelku ch10-git-internals.asc, kjer smo na kratko uporabili in pojasnili uporabo možnosti --ignore-unmatch
pri izvajanju ukaza git filter-branch
, kar preprosto preprečuje, da bi se pojavila napaka, ko datoteke, ki jih želimo odstraniti, ni.
To je lahko uporabno za namene skriptiranja.
Ukaz git mv
je preprost ukaz, ki omogoča premikanje datotek in nato se izvede ukaz git add
na novi datoteki ter ukaz git rm
na stari datoteki.
Ta ukaz smo samo na kratko omenili v razdelku ch02-git-basics-chapter.asc.
Ukaz git clean
se uporablja za odstranjevanje nepotrebnih datotek iz vašega delovnega direktorija.
To lahko vključuje odstranjevanje začasnih artefaktov gradnje ali datotek z združitvenimi konflikti.
Veliko možnosti in scenarijev, v katerih bi uporabili ukaz clean
, smo obravnavali v razdelku ch07-git-tools.asc.
V Gitu obstaja kar nekaj ukazov, ki omogočajo večino funkcionalnosti razvejanja in združevanja.
Ukaz git branch
je v resnici nekakšno orodje za upravljanje vej.
Omogoča vam izpis seznama vej, ustvarjanje novih vej, brisanje in preimenovanje vej.
Večina poglavja ch03-git-branching.asc je namenjenega ukazu branch
, ki ga uporabljamo skozi celotno poglavje.
Prvič smo ga predstavili v razdelku ch03-git-branching.asc, večino njegovih drugih funkcij (seznam in brisanje) pa smo opisali v razdelku ch03-git-branching.asc.
V razdelku ch03-git-branching.asc smo uporabili možnost git branch -u
, da nastavimo sledenje veji.
Na koncu pa smo opisali nekaj njegovih ozadij v razdelku ch10-git-internals.asc.
Ukaz git checkout
se uporablja za preklapljanje med vejami in izvlečenje vsebine v delovni imenik.
Prvič smo se srečali z ukazom v razdelku ch03-git-branching.asc skupaj z ukazom git branch
.
V razdelku ch03-git-branching.asc smo prikazali, kako ga uporabiti za sledenje vejam z zastavico --track
.
V razdelku ch07-git-tools.asc smo ga uporabili, da ponovno uvedemo konflikte med datotekami z --conflict=diff3
.
V razdelku ch07-git-tools.asc smo podrobneje opisali njegovo razmerje z ukazom git reset
.
Na koncu pa v razdelku ch10-git-internals.asc smo podrobneje opisali njegovo izvajanje.
Orodje git merge
se uporablja za združevanje ene ali več vej v vejo, ki jo imate odprto.
Nato se trenutna veja premakne na rezultat združevanja.
Ukaz git merge
je bil prvič predstavljen v razdelku ch03-git-branching.asc.
Čeprav se v knjigi uporablja na različnih mestih, obstaja zelo malo različic ukaza merge
— običajno samo git merge <branch>
z imenom ene veje, ki jo želite združiti.
V razdelku ch05-distributed-git.asc smo na koncu obravnavali združevanje z zdrobljenim zgodovinskim zapisom (kjer Git združi delo, vendar se pretvarja, kot da gre samo za novo potrditev, brez beleženja zgodovine veje, ki jo združujete).
V razdelku ch07-git-tools.asc smo se veliko naučili o postopku in ukazu za združevanje, vključno z ukazom -Xignore-space-change
in zastavico --abort
za prekinitev težavnega združevanja.
Naučili smo se preverjati podpise pred združevanjem, če vaš projekt uporablja podpisovanje z GPG, v razdelku ch07-git-tools.asc.
Na koncu smo se v razdelku ch07-git-tools.asc naučili o združevanju poddreves.
Ukaz git mergetool
enostavno zažene zunanji pripomoček za združevanje v primeru težav pri združevanju v Gitu.
Omenili smo ga na hitro v ch03-git-branching.asc in podrobneje razložili, kako lahko implementirate svoj lastni zunanji pripomoček za združevanje v ch08-customizing-git.asc.
Ukaz git log
se uporablja za prikazovanje dosegljive zabeležene zgodovine projekta od najnovejše zabeležene različice nazaj.
Privzeto prikazuje samo zgodovino veje, na kateri trenutno ste, vendar lahko navedete drugačne ali celo več glav ali vej, od katerih se želite premikati.
Pogosto se uporablja tudi za prikaz razlik med dvema ali več vejami na ravni potrditev.
Ta ukaz se uporablja v skoraj vsakem poglavju knjige za prikazovanje zgodovine projekta.
Ukaz smo predstavili in ga podrobno obravnavali v ch02-git-basics-chapter.asc.
Tam smo si ogledali možnosti -p
in --stat
, da dobimo idejo, kaj je bilo predstavljeno v vsaki potrditvi, in možnosti --pretty
in --oneline
, da si zgodovino ogledamo bolj jedrnato, skupaj s preprostimi možnostmi filtriranja po datumu in avtorju.
V ch03-git-branching.asc smo ga uporabili z možnostjo --decorate
, da si lažje vizualiziramo, kje so kazalniki naših vej, in uporabimo tudi možnost --graph
, da si ogledamo, kako so videti različne zgodovine.
V razdelkih ch05-distributed-git.asc in ch07-git-tools.asc smo pokrili sintakso branchA..branchB
pri uporabi ukaza git log
, da vidimo, katere potrditve so edinstvene za vejo v primerjavi z drugo vejo.
V ch07-git-tools.asc smo to precej obsežno obravnavali.
V razdelkih ch07-git-tools.asc in ch07-git-tools.asc smo pokrili uporabo formata branchA…branchB
in sintakse --left-right
, da vidimo, kaj je v eni veji ali drugi, vendar ne v obeh.
V razdelku ch07-git-tools.asc smo si ogledali tudi, kako uporabiti možnost --merge
za pomoč pri odpravljanju konfliktov med združevanjem, in uporabo možnosti --cc
, da si ogledamo konflikte pri združevanju potrditev v zgodovini.
V razdelku ch07-git-tools.asc smo uporabili možnost -g
, da si ogledamo Gitov reflog prek te orodne vrstice, namesto da bi prehajali po vejah.
V razdelku ch07-git-tools.asc smo si ogledali uporabo možnosti -S
in -L
za izvajanje precej zapletenih iskanj po nečem, kar se je zgodilo v zgodovini kode, kot je npr. ogled zgodovine funkcije.
V razdelku ch07-git-tools.asc smo se naučili, kako uporabiti --show-signature
, da dodamo potrditveno verigo k vsaki potrditvi v izpisu git log
glede na to, ali je bilo pravilno podpisano ali ne.
Ukaz git stash
se uporablja za shrambo nezaključenega dela na varno, da se očisti delovni direktorij, ne da bi bilo treba nedokončano delo potrditi na veji.
To je v bistvu v celoti pokrito v razdelku ch07-git-tools.asc.
Ukaz git tag
se uporablja za dodajanje trajnih zaznamkov določeni točki v zgodovini kode.
Navadno se uporablja za stvari, kot so izdaje.
Ta ukaz je predstavljen in podrobno obravnavan v razdelku ch02-git-basics-chapter.asc in ga v praksi uporabljamo v razdelku ch05-distributed-git.asc.
Prav tako smo obravnavali, kako ustvariti z GPG podpisano oznako z zastavico -s
in kako jo preveriti z zastavico -v
v razdelku ch07-git-tools.asc.
V Gitu ni veliko ukazov, ki dostopajo do omrežja, saj skoraj vsi ukazi delujejo na lokalni podatkovni bazi. Ko ste pripravljeni deliti svoje delo ali povleči spremembe od drugod, obstaja nekaj ukazov, ki se ukvarjajo z oddaljenimi repozitoriji.
Ukaz git fetch
se poveže z oddaljenim repozitorijem in prenese vse informacije iz njega, ki niso v vašem trenutnem repozitoriju, ter jih shrani v vašo lokalno podatkovno bazo.
Ta ukaz smo najprej obravnavali v razdelku ch02-git-basics-chapter.asc in nadaljevali z ogledom primerov uporabe v razdelku ch03-git-branching.asc.
Uporabljali smo ga tudi v več primerih v ch05-distributed-git.asc.
V ch06-github.asc smo ga uporabljali za prenos posamezne specifične reference, ki je zunaj privzetega prostora, in v ch07-git-tools.asc smo pogledali, kako prenesti iz paketa.
V ch10-git-internals.asc smo nastavili zelo prilagojene referenčne specifikacije, da git fetch
opravi nekoliko drugačno dejanje kot privzeto.
Ukaz git pull
je v bistvu kombinacija ukazov git fetch
in git merge
, pri čemer Git prenese iz oddaljenega repozitorija, ki ga določite, in ga takoj poskuša združiti v vejo, na kateri ste.
Ukaz smo na hitro predstavili v ch02-git-basics-chapter.asc in prikazali, kako videti, kaj bo združeno, če ga zaženete v ch02-git-basics-chapter.asc.
Prikazali smo tudi, kako ga uporabiti za pomoč pri težavah s ponovnim baziranjem v ch03-git-branching.asc.
Prikazali smo, kako ga uporabiti z URL-jem za enkratno pridobivanje sprememb v ch05-distributed-git.asc.
Na koncu smo v razdelku ch07-git-tools.asc zelo na hitro omenili, da mu lahko s stikalom --verify-signatures
omogočimo preverjanje, ali so potrditve, ki jih pridobivamo, podpisane z GPG.
Ukaz git push
se uporablja za komunikacijo z drugim repozitorijem, izračuna razliko med lokalno bazo podatkov in oddaljeno bazo podatkov ter to razliko potisne v drug repozitorij.
Potreben je dostop za pisanje do drugega repozitorija in običajno je na nekakšen način overjen.
Najprej smo si ogledali ukaz git push
v razdelku ch02-git-basics-chapter.asc.
Tukaj smo pokrili osnove potiskanja veje v oddaljeni repozitorij.
V razdelku ch03-git-branching.asc smo šli nekoliko globlje v potiskanje specifičnih vej in v razdelku ch03-git-branching.asc smo si pogledali, kako nastaviti sledenje vej, da se samodejno potisnejo.
V razdelku ch03-git-branching.asc smo uporabili zastavico --delete
, da izbrišemo vejo na strežniku z git push
.
Skozi razdelek ch05-distributed-git.asc smo si ogledali več primerov uporabe git push
za deljenje dela na vejah preko več oddaljenih repozitorijev.
V razdelku ch02-git-basics-chapter.asc smo videli, kako ga uporabiti za deljenje oznak, ki ste jih ustvarili, z uporabo možnosti --tags
.
V razdelku ch07-git-tools.asc smo uporabili možnost --recurse-submodules
, da smo preverili, ali je bilo vse delo z našimi podmoduli objavljeno, preden potisnemo nadrejeni projekt, kar je lahko resnično koristno pri uporabi podmodulov.
V razdelku ch08-customizing-git.asc smo na kratko govorili o kljuki pre-push
, ki je skript, ki ga lahko nastavimo, da se izvede pred končanjem potiskanja, da preveri, ali je potiskanje dovoljeno.
Na koncu, smo si v razdelku ch10-git-internals.asc ogledali potiskanje z uporabo celotnega refspeca namesto splošnih bližnjic, ki se običajno uporabljajo. To vam lahko pomaga, da boste zelo specifični glede dela, ki ga želite deliti.
Ukaz git remote
je upravljavsko orodje za vaše zapise oddaljenih repozitorijev.
Omogoča vam, da dolge URL-je shranite kot kratke oprimke, kot je »origin«, tako da jih ni treba vedno vpisovati.
Lahko imate več takih oprimkov in ukaz git remote
se uporablja za dodajanje, spreminjanje in brisanje teh oprimkov.
Ta ukaz je podrobno opisan v razdelku ch02-git-basics-chapter.asc, vključno s seznamom, dodajanjem, odstranjevanjem in preimenovanjem oprimku.
Uporablja se skoraj v vsakem nadaljnjem razdelku v knjigi, vendar vedno v standardnem formatu git remote add <name> <url>
.
Ukaz git archive
se uporablja za ustvarjanje stisnjene arhivske datoteke določenega posnetka projekta.
git archive
smo uporabili za ustvarjanje stisnjega arhiva tar (angl. tarball) projekta za deljenje v ch05-distributed-git.asc.
Ukaz git submodule
se uporablja za upravljanje zunanjih repozitorijev znotraj normalnih repozitorijev.
To bi lahko bilo za knjižnice ali druge vrste skupnih virov.
Ukaz submodule
ima več podukazov (add
, update
, sync
itd.) za upravljanje teh virov.
Ta ukaz je omenjen in v celoti pokrit samo v razdelku ch07-git-tools.asc.
Ukaz git show
lahko prikaže objekt Gita na preprost in človeku berljiv način.
Običajno bi ga uporabili za prikaz informacij o oznaki ali potrditvi.
Prvič ga uporabimo za prikaz informacij o anotiranih oznakah v razdelku ch02-git-basics-chapter.asc.
Kasneje smo ga precej uporabljali v razdelku ch07-git-tools.asc za prikaz potrditev, do katerih pridemo z različnimi izbirami revizij.
Ena od bolj zanimivih stvari, ki jih naredimo z git show
, je v razdelku ch07-git-tools.asc, kjer izvlečemo vsebino določenih datotek iz različnih stopenj med konfliktom združevanja.
Ukaz git shortlog
se uporablja za povzetek izhoda ukaza git log
.
Uporablja veliko istih možnosti kot ukaz git log
, vendar namesto naštevanja vseh potrditev prikaže povzetek potrditev razvrščenih po avtorju.
V razdelku ch05-distributed-git.asc smo pokazali, kako ga uporabiti za ustvarjanje lepega dnevnika sprememb.
Ukaz git describe
se uporablja za karkoli, kar se razreši v potrditev in proizvede niz, ki je bolj čitljiv za človeka in se ne bo spremenil.
To je način, kako dobiti opis potrditve, ki je tako nedvoumna kot SHA-1 potrditve, vendar bolj razumljiv.
Ukaz git describe
smo uporabili v razdelkih ch05-distributed-git.asc in ch05-distributed-git.asc, da smo dobili niz za poimenovanje naše datoteke za izdajo.
Git ima nekaj ukazov, ki se uporabljajo za odpravljanje napak v vaši kodi. To sega od ugotavljanja, kje je bilo nekaj uvedeno, do ugotavljanja, kdo je to uvedel.
Orodje git bisect
je neverjetno uporabno za odpravljanje napak in se uporablja za ugotavljanje, katera potrditev je prva povzročila napako ali težavo, s samodejnim binarnim iskanjem.
V celoti je opisano v ch07-git-tools.asc in je omenjeno samo v tem razdelku.
Ukaz git blame
označuje vrstice katere koli datoteke s potrditvijo, ki je bila zadnja, ki je uvedla spremembo v vsako vrstico datoteke, in kdo je ta potrditev ustvaril.
To je koristno, da najdete osebo, ki jo lahko povprašate po dodatnih informacijah o določenem delu svoje kode.
Opisan je v razdelku ch07-git-tools.asc in se omeni samo v tem razdelku.
Ukaz git grep
vam lahko pomaga najti kateri koli niz ali redni izraz v kateri koli datoteki vaše izvorne kode, tudi v starejših različicah vašega projekta.
Opisan je v razdelku ch07-git-tools.asc in se omeni samo v tem razdelku.
Nekaj ukazov v Gitu se osredotoča na zasnovo razmišljanja o potrditvah glede na spremembe, ki jih uvajajo, kot da bi bile serija potrditev serija popravkov. Ti ukazi vam pomagajo upravljati veje na ta način.
Ukaz git cherry-pick
se uporablja za jemanje spremembe, uvedene v eni potrditvi Gita, in jo poskuša ponovno uvesti kot novo potrditev na veji, na kateri trenutno delate.
To je lahko koristno, če želite vzeti samo eno ali dve potrditvi iz veje posamezno, namesto da bi združili celotno vejo, ki vključuje vse spremembe.
Postopek izbire najboljšega (angl. cherry picking) je opisan in prikazan v ch05-distributed-git.asc.
Ukaz git rebase
je v bistvu avtomatizirana funkcija cherry-pick
.
Določi serijo potrditev in jih nato posamično po najbolje izbranih ponovno uvede drugje v istem vrstnem redu.
Postopek ponovnega baziranja je podrobno opisan v razdelku ch03-git-branching.asc in vključuje tudi obravnavo težav sodelovanja, ki nastanejo pri ponovni uvedbi vej, ki so že javne.
V praksi ga uporabljamo med primerom razdelitve zgodovine na dva ločena repozitorija v razdelku ch07-git-tools.asc, kjer uporabljamo tudi zastavico --onto
.
V razdelku ch07-git-tools.asc smo se srečali s konfliktom združevanja med postopkom ponovnega baziranja.
Prav tako smo ga uporabili v interaktivnem načinu skriptiranja z možnostjo -i
v razdelku ch07-git-tools.asc.
Ukaz git revert
je v bistvu obraten od git cherry-pick
.
Ustvari novo potrditev, ki uporabi natančno nasprotno spremembo, kot je bila vpeljana v izbrani potrditvi, v bistvu pa jo razveljavi ali povrne nazaj.
Uporabili smo ga v ch07-git-tools.asc, da smo razveljavili potrditev združevanja.
Mnogi projekti Git, vključno z Git samim, se v celoti vzdržujejo preko seznamov za pošiljanje e-pošte. Git ima vgrajena orodja, ki pomagajo olajšati ta proces, od ustvarjanja popravkov, ki jih lahko enostavno pošljete po e-pošti, do uporabe teh popravkov iz poštnega nabiralnika.
Ukaz git apply
uporabi programski popravek, ustvarjen z ukazom git diff
ali celo z ukazom GNU diff.
Podobno kot ukaz patch
naredi z nekaj manjšimi razlikami.
V razdelku ch05-distributed-git.asc smo predstavili uporabo in okoliščine, v katerih ga lahko uporabimo.
Ukaz git am
se uporablja za uporabo programskih popravkov iz poštnega nabiralnika, posebej tistega, ki je oblikovan kot mbox.
To je uporabno za prejemanje popravkov preko e-pošte in njihovo enostavno uporabo v projektu.
Pokrili smo uporabo in potek dela okoli git am
v ch05-distributed-git.asc, vključno z uporabo možnosti --resolved
, -i
in -3
.
Obstaja tudi veliko število kljuk, ki jih lahko uporabite za pomoč pri poteku dela okoli git am
, in vse so opisane v razdelku ch08-customizing-git.asc.
Uporabimo ga tudi za uporabo sprememb oblikovanih kot popravki za zahteve potegov na GitHubu v razdelku ch06-github.asc.
Ukaz git format-patch
se uporablja za ustvarjanje zaporedja popravkov v formatu mbox, ki jih lahko uporabite za pošiljanje na seznamu pošte v pravilno oblikovani obliki.
V primeru sodelovanja v projektu z uporabo orodja git format-patch
smo šli skozi v razdelku ch05-distributed-git.asc.
Ukaz git imap-send
omogoča nalaganje nabiralnika, ki je ustvarjen z orodjem git format-patch
, v IMAP osnutke mape.
V razdelku ch05-distributed-git.asc smo prikazali primer, kako prispevati k projektu s pošiljanjem popravkov s pomočjo orodja git imap-send
.
Ukaz git send-email
se uporablja za pošiljanje popravkov, ki so ustvarjeni z git format-patch
preko e-pošte.
V razdelku ch05-distributed-git.asc smo prikazali primer, kako prispevati k projektu s pošiljanjem popravkov s pomočjo orodja git send-email
.
Ukaz git request-pull
se preprosto uporablja za generiranje sporočila, ki se pošlje po e-pošti.
Če imate vejo na javnem strežniku in želite nekoga obvestiti, kako integrirati te spremembe brez pošiljanja popravkov preko e-pošte, lahko zaženete ta ukaz in pošljete izpis osebi, ki naj prevzame spremembe.
V razdelku ch05-distributed-git.asc smo prikazali, kako uporabiti git request-pull
za generiranje sporočila o prevzemu.
Git ima nekaj ukazov za integracijo z drugimi sistemi za nadzor različic.
Ukaz git svn
se uporablja za komunikacijo s sistemom za nadzor različic Subversion kot odjemalec.
To pomeni, da lahko uporabite Git za izvlečenje in potrjevanje na strežnik Subversion.
Ta ukaz je podrobno opisan v razdelku ch09-git-and-other-systems.asc.
Za druge sisteme za nadzor različic ali uvoz iz skoraj katerega koli formata lahko uporabite git fast-import
, da hitro preslikate drug format v nekaj, kar lahko Git enostavno beleži.
Ta ukaz je podrobno opisan v razdelku ch09-git-and-other-systems.asc.
Če upravljate repozitorij Git ali morate nekaj popraviti na velik način, Git ponuja številne upravljavske ukaze, ki vam lahko pomagajo.
Ukaz git gc
sproži »sproščanje pomnilnika« (angl. garbage collection) v vašem repozitoriju, odstranjuje nepotrebne datoteke iz vaše zbirke podatkov in preostale datoteke združi v bolj učinkovit format.
Ta ukaz običajno zažene v ozadju, lahko pa ga zaženete ročno, če želite. Nekaj primerov tega je v razdelku ch10-git-internals.asc.
Ukaz git fsck
se uporablja za preverjanje notranje zbirke podatkov za težave ali neskladnosti.
To smo uporabili samo hitro enkrat v razdelku ch10-git-internals.asc, da smo poiskali viseče objekte.
Ukaz git reflog
pregleda dnevnik, kje so bile glave vaših vej med delom, da najdete potrditve, ki ste jih morda izgubili s spreminjanjem zgodovine.
Ta ukaz smo obravnavali predvsem v ch07-git-tools.asc, kjer smo prikazali normalno uporabo in kako z uporabo git log -g
videti enake informacije kot v izpisih git log
.
Prav tako smo prikazali praktičen primer obnavljanja takšne izgubljene veje v ch10-git-internals.asc.
Ukaz git filter-branch
se uporablja za prepisovanje veliko potrditev v skladu z določenimi vzorci, kot so odstranjevanje datoteke povsod ali filtriranje celotnega repozitorija v eno podmapo za izvleček projekta.
V ch07-git-tools.asc smo pojasnili ukaz in raziskali več različnih možnosti, kot so --commit-filter
, --subdirectory-filter
in --tree-filter
.
V ch09-git-and-other-systems.asc smo ga uporabili za popravilo uvoženih zunanjih repozitorijev.
V knjigi smo naleteli tudi na veliko število nižje nivojskih orodij sistema napeljave.
Prvo orodje, s katerim se srečamo, je ls-remote
v ch06-github.asc, ki ga uporabimo za ogled surovih referenc na strežniku.
ls-files
smo uporabili v razdelkih ch07-git-tools.asc, ch07-git-tools.asc in ch07-git-tools.asc za ogled podrobnosti o vašem področju priprave.
V ch07-git-tools.asc smo omenili tudi rev-parse
, ki omogoča pretvorbo skoraj katerega koli niza v objekt SHA-1.
Večina nizko nivojskih orodij sistema napeljave, ki smo jih obravnavali, pa je v ch10-git-internals.asc, na kar je poglavje večinoma osredotočeno. Njihovi uporabi smo se poskušali izogniti skozi večino preostale knjige.