-
1. Začetek
- 1.1 O nadzoru različic
- 1.2 Kratka zgodovina Gita
- 1.3 Kaj je Git?
- 1.4 Ukazna vrstica
- 1.5 Namestitev Gita
- 1.6 Prva nastavitev Gita
- 1.7 Pridobivanje pomoči
- 1.8 Povzetek
-
2. Osnove Git
- 2.1 Pridobivanje repozitorija Git
- 2.2 Snemanje sprememb v repozitorij
- 2.3 Pregled zgodovine potrditev
- 2.4 Razveljavljanje stvari
- 2.5 Delo z daljavami
- 2.6 Označevanje
- 2.7 Aliasi Git
- 2.8 Povzetek
-
3. Veje Git
- 3.1 Veje na kratko
- 3.2 Osnove vej in združevanja
- 3.3 Upravljanje vej
- 3.4 Poteki dela z vejami
- 3.5 Oddaljene veje
- 3.6 Ponovno baziranje
- 3.7 Povzetek
-
4. Git na strežniku
- 4.1 Protokoli
- 4.2 Pridobitev Gita na strežniku
- 4.3 Generiranje vaših javnih ključev SSH
- 4.4 Nastavitev strežnika
- 4.5 Prikriti proces Git
- 4.6 Pametni HTTP
- 4.7 GitWeb
- 4.8 GitLab
- 4.9 Možnosti gostovanja pri tretjih ponudnikih
- 4.10 Povzetek
-
5. Porazdeljeni Git
- 5.1 Porazdeljeni poteki dela
- 5.2 Prispevek k projektu
- 5.3 Vzdrževanje projekta
- 5.4 Povzetek
-
6. GitHub
-
7. Orodja Git
- 7.1 Izbira revizije
- 7.2 Interaktivno pripravljanje
- 7.3 Shranjevanje na varno (angl. stashing) in čiščenje
- 7.4 Podpisovanje vašega dela
- 7.5 Iskanje
- 7.6 Prepisovanje zgodovine
- 7.7 Demistifikacija ponastavitve
- 7.8 Napredno združevanje
- 7.9 Rerere
- 7.10 Razhroščevanje z Gitom
- 7.11 Podmoduli
- 7.12 Povezovanje v pakete
- 7.13 Zamenjava
- 7.14 Shramba poverilnic
- 7.15 Povzetek
-
8. Prilagoditev Gita
- 8.1 Konfiguracija Git
- 8.2 Atributi Git
- 8.3 Kljuke Git
- 8.4 Primer pravilnika, ki ga uveljavlja Git
- 8.5 Povzetek
-
9. Git in ostali sistemi
- 9.1 Git kot odjemalec
- 9.2 Migracija na Git
- 9.3 Povzetek
-
10. Notranjost Gita
- 10.1 Napeljava in keramika
- 10.2 Objekti Git
- 10.3 Reference Git
- 10.4 Packfiles (datoteke zmanjšanih podatkov)
- 10.5 Refspec
- 10.6 Protokoli prenosa
- 10.7 Vzdrževanje in obnovitev podatkov
- 10.8 Spremenljivke okolja
- 10.9 Povzetek
-
A1. Dodatek A: Git v drugih okoljih
- A1.1 Grafični vmesniki
- A1.2 Git v Visual Studio
- A1.3 Git v Visual Studio Code
- A1.4 Git v IntelliJ / PyCharm / WebStorm / PhpStorm / RubyMine
- A1.5 Git v Sublime Text
- A1.6 Git v Bashu
- A1.7 Git v Zsh
- A1.8 Git v Powershellu
- A1.9 Povzetek
-
A2. Dodatek B: Vdelava Gita v vašo aplikacijo
- A2.1 Git v ukazni vrstici
- A2.2 Libgit2
- A2.3 JGit
- A2.4 go-git
- A2.5 Dulwich
-
A3. Dodatek C: Ukazi Git
- A3.1 Nastavitev in konfiguracija
- A3.2 Pridobivanje in ustvarjanje projektov
- A3.3 Osnove posnetkov
- A3.4 Veje in združevanje
- A3.5 Deljenje in posodabljanje projektov
- A3.6 Pregled in primerjava
- A3.7 Razhroščevanje
- A3.8 Popravljanje
- A3.9 E-pošta
- A3.10 Zunanji sistemi
- A3.11 Administracija
- A3.12 Orodja za sisteme napeljave
5.3 Porazdeljeni Git - Vzdrževanje projekta
Vzdrževanje projekta
Poleg tega, da veste, kako učinkovito prispevati projektu, boste verjetno morali vedeti tudi, kako ga vzdrževati.
To lahko sestoji iz sprejemanja in uporabe popravkov generiranih preko format-patch
, ki so vam poslani preko e-pošte, ali integracije sprememb v oddaljenih vejah za repozitorije, ki ste jih dodali kot daljave v svoj projekt.
Bodisi če vzdržujete kanonični repozitorij ali želite pomagati s potrditvijo ali odobritvijo popravkov, morate vedeti, kako sprejeti delo na način, ki je najbolj jasen za druge, ki prispevajo, in trajnosten na dolgi rok.
Delo na tematskih vejah
Ko razmišljate o integraciji novega dela, je v splošnem dobra ideja poskusiti na tematski veji — začasni veji, posebej narejeni za preskušanje tega novega dela.
Na ta način je enostavno prilagoditi programski popravek individualno, ali pa ga pustiti, če ne deluje, dokler nimate časa se vrniti nazaj k njemu.
Če ustvarite enostavno ime veje na osnovi teme dela, ki ga boste poskusili, kot je ruby_client
ali nekaj podobno opisljivega, si lahko enostavno zapomnite, če jo morate opustiti za nekaj časa in se kasneje vrniti.
Vzdrževalec projekta Git tudi stremi k poimenovanju teh vej v imenskem prostoru — kot je sc/ruby_client
, kjer je sc
kratica za osebo, ki je prispevala delo.
Kot se boste spomnili, lahko ustvarite vejo na osnovi vaše veje master
takole:
$ git branch sc/ruby_client master
Ali če želite takoj nanjo tudi preklopiti, lahko uporabite možnost checkout -b
:
$ git checkout -b sc/ruby_client master
Sedaj ste pripravljeni dodati prispevano delo, ki ste ga prejeli, v to tematsko vejo in določiti, ali jo želite združiti v svoje dolgotrajne veje.
Uporaba popravkov iz e-pošte
Če prejmete programski popravek, ki ga morate integrirati v svoj projekt, preko e-pošte, morate uporabiti popravek na svoji tematski veji, da ga ocenite.
Na voljo sta dva načina za uporabo e-poštnega popravka: z git apply
ali z git am
.
Uporaba popravka z apply
Če prejmete programski popravek od nekoga, ki ga je generiral z git diff
ali kakšno variacijo ukaza Unix diff
(kar ni priporočljivo; glejte naslednji razdelek), ga lahko uporabite z ukazom git apply
.
Predpostavljamo, da ste shranili programski popravek v /tmp/patch-ruby-client.patch
, lahko uporabite popravek na naslednji način:
$ git apply /tmp/patch-ruby-client.patch
To spremeni datoteke v vašem delovnem direktoriju.
Je skoraj identično pogonu ukaza patch -p1
, da uporabite programski popravek, vendar je bolj paranoično in sprejema manj nejasna ujemanja kot popravek.
Upravlja tudi dodajanja datotek, brisanja in preimenovanja, če so opisana v obliki git diff
, kar patch
ne naredi.
Na koncu git apply
je model »uporabi vse ali prekliči vse«, kjer je uporabljeno vse ali nič, z razliko, kjer patch
lahko delno uporablja datoteke popravkov, kar pusti vaš delovni direktorij v čudnem stanju.
git apply
je splošno veliko bolj konzervativen kot patch
.
Ne bo ustvaril potrditve za vas — po tem, ko ga poženete, morate ročno dati v področje priprave in potrditi uvedene spremembe.
git apply
lahko uporabite tudi, da vidite, če se programski popravek lahko gladko uporabi, preden ga poskusite dejansko uporabiti — poženete lahko git apply --check
s popravkom:
$ git apply --check 0001-see-if-this-helps-the-gem.patch
error: patch failed: ticgit.gemspec:1
error: ticgit.gemspec: patch does not apply
Če ni nobenega izpisa, potem bi se moral programski popravek uporabiti gladko. Ta ukaz se tudi konča z neničelnim statusom, če preverjanje ni uspešno, tako da ga lahko uporabite v skriptih, če želite.
Uporaba popravka z am
Če je uporabnik, ki prispeva, uporabnik Git in je bilo dovolj dobro uporabiti ukaz format-patch
za generiranje njegovega popravka, potem je vaše delo enostavnejše, saj programski popravek vsebuje informacije avtorja in sporočilo potrditve za vas.
Če lahko, spodbudite svoje sodelavce, da uporabljajo format-patch
namesto diff
za generiranje popravkov za vas.
git apply
bi morali uporabiti samo pri opuščenih popravkih in podobnih stvareh.
Da uporabite programski popravek generiran s format-patch
, uporabite git am
(ukaz se imenuje am
, ker pomeni »uporabi (angl. apply) serijo popravkov iz mailboxa«).
Tehnično je git am
zgrajen, da prebere datoteko mbox, ki je enostaven tekstovni format za shranjevanje enega ali več e-poštnih sporočil v eni tekstovni datoteki.
Videti je nekako takole:
From 330090432754092d704da8e76ca5c05c198e71a8 Mon Sep 17 00:00:00 2001
From: Jessica Smith <jessica@example.com>
Date: Sun, 6 Apr 2008 10:17:23 -0700
Subject: [PATCH 1/2] Add limit to log function
Limit log functionality to the first 20
To je začetek izhodnega zapisa ukaza git format-patch
, ki ste ga videli v prejšnjem odseku; predstavlja tudi veljaven e-poštni format mbox.
Če vam nekdo pravilno pošlje programski popravek z uporabo ukaza git send-email
in ga prenesete v obliki mbox, lahko git am
usmerite v datoteko mbox in začne uporabljati vse popravke, ki jih vidi.
Če uporabljate odjemalca pošte, ki lahko več e-poštnih sporočil shranjuje v obliki mbox, lahko celotno serijo popravkov shranite v datoteko in nato uporabite git am
, da jih uporabite enega za drugim.
Če pa je nekdo naložil datoteko s popravkom, ki je bila ustvarjena prek ukaza git format-patch
v sistem za beleženje težav ali kaj podobnega, lahko datoteko shranite lokalno in jo nato prenesete v git am
, da jo uporabite:
$ git am 0001-limit-log-function.patch
Applying: Add limit to log function
Vidite lahko, da se je programski popravek uporabil brez težav in samodejno ustvaril novo potrditev za vas.
Informacije o avtorju so vzete iz glav From
in Date
v e-pošti, sporočilo potrditve pa je vzeto iz Subject
in telesa (pred popravkom) e-pošte.
Če je bil na primer ta programski popravek uporabljen iz zgornjega primera mbox, bi bila ustvarjena potrditev nekaj podobnega temu:
$ git log --pretty=fuller -1
commit 6c5e70b984a60b3cecd395edd5b48a7575bf58e0
Author: Jessica Smith <jessica@example.com>
AuthorDate: Sun Apr 6 10:17:23 2008 -0700
Commit: Scott Chacon <schacon@gmail.com>
CommitDate: Thu Apr 9 09:19:06 2009 -0700
Add limit to log function
Limit log functionality to the first 20
Informacije Commit
kažejo osebo, ki je uporabila programski popravek, in čas uporabe.
Informacije Author
pa kažejo na osebo, ki je prvotno ustvarila programski popravek in kdaj je bil prvotno ustvarjen.
Vendar lahko se zgodi, da se programski popravek ne bo uporabil brez težav.
Morda se je vaša glavna veja preveč oddaljila od veje, iz katere je bil programski popravek zgrajen, ali pa je popravek odvisen od drugega popravka, ki ga še niste uporabili.
V tem primeru bo proces git am
spodletel in vas vprašal, kaj želite storiti:
$ git am 0001-see-if-this-helps-the-gem.patch
Applying: See if this helps the gem
error: patch failed: ticgit.gemspec:1
error: ticgit.gemspec: patch does not apply
Patch failed at 0001.
When you have resolved this problem run "git am --resolved".
If you would prefer to skip this patch, instead run "git am --skip".
To restore the original branch and stop patching run "git am --abort".
Ta ukaz vstavi označevalce konfliktov v datoteke, s katerimi ima težave, podobno kot pri operaciji združevanja ali ponovnem baziranju, ki ima konflikte.
To težavo lahko rešite na podoben način — uredite datoteko, da rešite konflikt, shranite novo datoteko in nato zaženite git am --resolved
, da nadaljujete na naslednji programski popravek:
$ (fix the file)
$ git add ticgit.gemspec
$ git am --resolved
Applying: See if this helps the gem
Če želite, da Git poskusi bolj inteligentno rešiti konflikt, mu lahko podate možnost -3
, kjer Git poskuša izvesti tristransko združevanje.
Ta možnost ni privzeto vklopljena, ker ne deluje, če potrditve, ki jih navaja programski popravek, ni v vašem repozitoriju.
Če imate to potrditev — če je bil programski popravek ustvarjen na podlagi javne potrditve — je možnost -3
na splošno veliko bolj inteligentna pri uporabi konfliktnega popravka:
$ git am -3 0001-see-if-this-helps-the-gem.patch
Applying: See if this helps the gem
error: patch failed: ticgit.gemspec:1
error: ticgit.gemspec: patch does not apply
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
No changes -- Patch already applied.
V tem primeru bi bil programski popravek brez možnosti -3
obravnavan kot konflikt.
Ker je bila uporabljena možnost -3
, se je programski popravek uporabil brez težav.
Če uporabljate več popravkov iz mboxa, lahko ukaz am
zaženete tudi v interaktivnem načinu, ki se ustavi pri vsakem popravku, ki ga najde, in vpraša, ali ga želite uporabiti:
$ git am -3 -i mbox
Commit Body is:
--------------------------
See if this helps the gem
--------------------------
Apply? [y]es/[n]o/[e]dit/[v]iew patch/[a]ccept all
To je koristno, če imate shranjenih več popravkov, saj si lahko programski popravek najprej ogledate, če se ne spomnite, kaj predstavlja, ali pa ga ne uporabite, če ste ga že uporabili.
Ko so vsi popravki za vašo temo uporabljeni in potrjeni v vaši razvojni veji, lahko izberete, ali jih želite integrirati v dolgotrajno vejo in na kakšen način.
Izvlečenje oddaljenih vej
Če je vaš prispevek prišel od uporabnika Git, ki je nastavil svoj lastni repozitorij, vanj potisnil več sprememb in vam nato poslal naslov URL repozitorija in ime oddaljene veje, v kateri so spremembe, jih lahko dodate kot oddaljeno vejo in nato lokalno združite.
Na primer, če vam Jessica pošlje e-poštno sporočilo, v katerem pravi, da ima odlično novo funkcijo v veji ruby-client
svojega repozitorija, jo lahko preizkusite tako, da dodate oddaljeno vejo in lokalno izvlečete to vejo:
$ git remote add jessica https://github.com/jessica/myproject.git
$ git fetch jessica
$ git checkout -b rubyclient jessica/ruby-client
Če vam pozneje ponovno pošlje e-pošto z drugo vejo, ki vsebuje drugo odlično funkcionalnost, jo lahko neposredno prenesete s fetch
in checkout
saj imate že nastavljen oddaljeni vir.
To je najbolj uporabno, če redno sodelujete s to osebo. Če nekdo prispeva le občasno kakšen programski popravek, je sprejemanje prek e-pošte manj časovno potratno, kot zahtevati, da vsakdo zažene svoj lastni strežnik in nenehno dodaja in odstranjuje daljave, da bi dobili nekaj sprememb. Verjetno tudi ne želite imeti na stotine daljav, vsake za vsako osebo, ki prispeva le eno ali dve spremembi. Vendar pa lahko skripti in gostujoče storitve to olajšajo — odvisno je predvsem od tega, kako razvijate in kako razvijajo vaši sodelavci.
Druga prednost tega pristopa je, da dobite tudi zgodovino opravljenih potrditev.
Čeprav imate lahko legitimne težave z združevanjem, veste, kje v vaši zgodovini je njihovo delo, saj je pravilno tristopenjsko združevanje privzeto, namesto da bi morali zagotoviti -3
in upati, da je oblika spremembe ustvarjena iz javne potrditve, do katere imate dostop.
Če ne sodelujete redno z osebo, vendar še vedno želite povleči od njih na ta način, lahko naslov URL oddaljenega repozitorija navedete v ukazu git pull
.
To naredi enkratno vlečenje in ne shrani URL-ja kot referenčnega oddaljenega vira:
$ git pull https://github.com/onetimeguy/project
From https://github.com/onetimeguy/project
* branch HEAD -> FETCH_HEAD
Merge made by the 'recursive' strategy.
Določanje, kaj se uvaja
Zdaj imate tematsko vejo, ki vsebuje prispevano delo. V tem trenutku lahko določite, kaj bi radi naredili z njim. Ta odsek ponovno pregleda nekaj ukazov, da lahko vidite, kako jih lahko uporabite za pregled tega, kaj boste uvedli, če ga združite v glavno vejo.
Pogosto je koristno, da pregledate vse potrditve, ki so v tej veji, vendar niso v vaši veji master
.
Potrditve v veji master
lahko izključite tako, da pred imenom veje dodate možnost --not
.
To stori isto kot oblika master..contrib
, ki smo jo uporabili prej.
Na primer, če vam sodelavec pošlje dve potrditvi in ustvarite vejo z imenom contrib
ter nanjo uporabite te potrditve, lahko zaženete:
$ git log contrib --not master
commit 5b6235bd297351589efc4d73316f0a68d484f118
Author: Scott Chacon <schacon@gmail.com>
Date: Fri Oct 24 09:53:59 2008 -0700
See if this helps the gem
commit 7482e0d16d04bea79d0dba8988cc78df655f16a0
Author: Scott Chacon <schacon@gmail.com>
Date: Mon Oct 22 19:38:36 2008 -0700
Update gemspec to hopefully work better
Da vidite, kaj spremembe vsake potrditve prinesejo, ne pozabite, da lahko podate ukazu git log
možnost -o
in pripel bo razliko predstavljeno v vsaki potrditvi.
Da bi videli celotno razliko, ki bi se zgodila, če bi to tematsko vejo združili z drugo vejo, boste morda morali uporabiti čuden trik, da dobite pravilne rezultate. Morda bi pomislili, da bi zagnali to:
$ git diff master
Ta ukaz vam da razliko, vendar je lahko zavajajoča.
Če se je vaša veja master
premaknila naprej od trenutka, ko ste iz nje ustvarili tematsko vejo, boste dobili na videz nenavadne rezultate.
To se zgodi, ker Git neposredno primerja posnetke zadnje potrditve na tematski veji, na kateri ste, in posnetka zadnje potrditve na veji master
.
Na primer, če ste na veji master
dodali vrstico v datoteko, bo neposredna primerjava posnetkov videti, kot da bo tematska veja odstranila to vrstico.
Če je master
neposredni prednik vaše tematske veje, to ni problem; toda če sta se zgodovini razhajali, se bo razlika zdela, kot da dodajate vse nove stvari na svoji tematski veji in odstranjujete vse, kar je edinstveno za vejo master
.
Kar želite videti, so spremembe, dodane v tematski veji — delo, ki ga boste uvedli, če boste združili to vejo z master
.
To dosežete tako, da Git primerja zadnjo potrditev na vaši tematski veji z zadnjim skupnim prednikom, ki ga ima z vejo master
.
Tehnično gledano, to lahko storite tako, da izrecno določite skupnega prednika in nato zaženete svojo razliko na njem:
$ git merge-base contrib master
36c7dba2c95e6bbb78dfa822519ecfec6e1ca649
$ git diff 36c7db
ali bolj jedrnato:
$ git diff $(git merge-base contrib master)
Vendar nobena od teh ni posebej priročna, zato Git ponuja še eno bližnjico za isto stvar: sintakso s tremi pikami.
V kontekstu ukaza git diff
lahko dodate tri pike po drugi veji, da naredite diff
med zadnjo potrditvijo na veji, na kateri ste, in njenim skupnim prednikom z drugo vejo:
$ git diff master...contrib
Ta ukaz prikaže samo delo, ki ga je vaša trenutna tematska veja vnesla od skupnega prednika z vejo master
.
To je zelo uporabna sintaksa, ki si jo velja zapomniti.
Integriranje prispevanega dela
Ko je vse delo v vaši tematski veji pripravljeno za integracijo v glavno vejo, se postavi vprašanje, kako to storiti. Poleg tega, kateri splošni potek dela želite uporabiti za vzdrževanje svojega projekta? Imate več možnosti, zato bomo obravnavali nekatere od njih.
Poteki dela združevanj
Eden izmed osnovnih potekov dela je, da preprosto združite vse delo neposredno v vašo vejo master
.
V tem scenariju imate vejo master
, ki vsebuje v bistvu stabilno kodo.
Ko imate delo v tematski veji, za katerega menite, da ste ga dokončali, ali delo, ki ga je prispeval nekdo drug in ste ga preverili, ga združite v vašo vejo master
, izbrišete tematsko vejo, ki ste jo ravno združili, ter ponovite.
Na primer, če imamo repozitorij z delom v dveh vejah imenovanih ruby_client
in php_client
, ki je videti kot na sliki Zgodovina z več tematskimi vejami, in združimo ruby_client
, nato pa še php_client
, bo vaša zgodovina videti kot na sliki Po združitvi tematske veje.
![Zgodovina z več tematskimi vejami](png/merging-workflows-1.png)
![Po združitvi tematske veje](png/merging-workflows-2.png)
To je verjetno najpreprostejši potek dela, vendar lahko pri delu z večjimi ali bolj stabilnimi projekti, kjer morate biti zelo previdni pri tem, kaj uvajate, povzroči težave.
Če imate pomembnejši projekt, bi morda želeli uporabiti dvofazni postopek združevanja.
V tem scenariju imate dve dolgotrajni veji, master
in develop
, pri katerih določite, da se master
posodobi le, ko je izdana zelo stabilna različica in se vsa nova koda integrira v vejo develop
.
Občasno obe veji potisnete v javni repozitorij.
Vsakič, ko želite združiti novo tematsko vejo (slika Pred združitvijo tematske veje), jo združite v vejo develop
(slika Po združitvi tematske veje); nato, ko označite izdajo, master
hitro posodobite do stabilne točke, kjer je trenutna veja develop
(slika Po objavi projekta).
![Pred združitvijo tematske veje](png/merging-workflows-3.png)
![Po združitvi tematske veje](png/merging-workflows-4.png)
![Po objavi projekta](png/merging-workflows-5.png)
Na ta način lahko ljudje, ki si klonirajo vaš repozitorij projekta, izvlečejo master
za gradnjo najnovejše stabilne različice in jo enostavno ohranjajo posodobljeno, ali pa preverijo develop
, ki vsebuje najnaprednejšo vsebino.
To zasnovo lahko razširite tudi tako, da imate vejo integrate
, v kateri se združi vse delo.
Nato, ko je koda na tej veji stabilna in uspešno preide teste, jo združite v vejo develop
, in ko se ta predstavi kot stabilna za več časa, posodobite vejo master
.
Poteki dela večjih združevanj
Projekt Git ima štiri dolgotrajne veje: master
, next
in seen
(prej pu
— predlagane posodobitve — angl. proposed updates) za novo delo in maint
za vzdrževanje posodobitev.
Ko prispe novo delo s strani sodelavcev, se zbere v tematskih vejah v repozitoriju vzdrževalca na način, podoben temu, kar smo opisali (glejte sliko Upravljanje kompleksne serije vzporednih prispevanih tematskih vej).
V tej fazi se ocenijo tematske veje, da se ugotovi, ali so varne in pripravljene za uporabo, ali potrebujejo še več dela.
Če so varne, se vgradijo v next
in ta veja se objavi, tako da lahko vsi preizkusijo teme, integrirane skupaj.
![Upravljanje kompleksne serije vzporednih prispevanih tematskih vej](png/large-merges-1.png)
Če teme še potrebujejo delo, so namesto tega združene v vejo seen
.
Ko se ugotovi, da so v celoti stabilne, se teme ponovno združi v vejo master
.
Veji next
in seen
sta nato znova zgrajeni iz master
.
To pomeni, da se master
skoraj vedno premika naprej, next
se občasno ponovno bazira in seen
se ponovno bazira še pogosteje:
![Združevanje prispevanih tematskih vej v dolgotrajne integracijske veje](png/large-merges-2.png)
Ko je tematska veja končno združena v master
, se izbriše iz repozitorija.
Projekt Git ima tudi vejo maint
, ki je razvejana od zadnje različice, da zagotavlja popravke za nazaj, če je potrebna vzdrževalna izdaja.
Tako imate pri kloniranju repozitorija Git štiri veje, ki jih lahko preizkusite, da ovrednotite projekt v različnih razvojnih fazah, odvisno od tega, kako drzni želite biti, ali kako želite prispevati; in vzdrževalec ima strukturiran potek dela, ki mu pomaga preverjati nove prispevke.
Potek dela projekta Git je specializiran.
Za boljše razumevanje si lahko ogledate Gitov vodnik za vzdrževanje.
Poteki dela ponovnega baziranja in izbire najboljšega
Drugi vzdrževalci raje ponovno bazirajo ali izberejo najboljše prispevano delo na vrh njihove veje master
, namesto da bi ga združili, da ohranijo predvsem linearno zgodovino.
Ko imate delo v tematski veji in ste ugotovili, da ga želite integrirati, se premaknete na to vejo in zaženete ukaz za ponovno baziranje (angl. rebase), da ponovno sestavite spremembe na vrhu trenutne veje master
(ali develop
in tako naprej).
Če to deluje dobro, lahko hitro previjete naprej vašo vejo master
in imeli boste linearno zgodovino projekta.
Drugi način za premikanje vpeljanega dela iz ene veje v drugo je t. i. izbiranje najboljšega (angl. cherry picking). Izbiranje najboljšega v Gitu je podobno ponovnem baziranju za eno samo potrditev. Vzame programski popravek, ki je bil uveden v eni potrditvi, in ga poskuša ponovno uporabiti na veji, na kateri trenutno ste. To je uporabno, če imate na veji več potrditev in želite integrirati le eno od njih, ali če imate samo eno potrditev na veji in bi jo raje izbrali kot najboljšo namesto ponovnega baziranja. Na primer, recimo, da imate projekt, ki je videti tako:
![Primer zgodovine pred izbiro najboljšega](png/rebasing-1.png)
Če želite povleči potrditev e43a6
v vašo vejo master
, lahko poženete:
$ git cherry-pick e43a6
Finished one cherry-pick.
[master]: created a0a41a9: "More friendly message when locking the index fails."
3 files changed, 17 insertions(+), 3 deletions(-)
To povleče iste spremembe, ki so bile predstavljene v e43a6
, vendar dobite novo vrednost SHA-1 potrditve, ker je uporabljeni datum drugačen.
Sedaj je vaša zgodovina videti takole:
![Zgodovina po izbiri najboljše potrditve iz tematske veje](png/rebasing-2.png)
Sedaj lahko odstranite svojo tematsko vejo in opustite potrditve, ki jih niste želeli povleči.
Rerere
Če delate veliko združevanja in ponovnega baziranja, ali vzdržujete dolgotrajno tematsko vejo, ima Git lastnost, ki se imenuje »rerere«, ki je lahko koristna.
Rerere pomeni »reuse recorded resolution« (ponovno uporabi posneto rešitev) — je način bližnjice ročnega reševanja konflikta. Ko je rerere omogočen, bo Git obdržal skupek slik pred in po iz uspešnih združitev in če opazi, da gre za konflikt, ki je videti točno tak kot eden, ki ste ga že popravili, bo enostavno samo uporabil programski popravek od zadnjič, ne da vas pri tem z njim moti.
Ta lastnost prihaja v dveh delih: konfiguracijska nastavitev in ukaz.
Konfiguracijska nastavitev je rerere.enabled
in je dovolj priročna, da jo dodate v svoje globalne nastavitve:
$ git config --global rerere.enabled true
Sedaj, vsakič, ko izvedete združevanje, ki rešuje konflikte, se bo rešitev zabeležila v predpomnilnik, če jo boste potrebovali v prihodnosti.
Če je treba, lahko z ukazom git rerere
interaktivno upravljate s predpomnilnikom rerere.
Ko se uporabi samostojno, Git preveri svojo bazo rešitev in poskuša najti ujemanje z morebitnimi trenutnimi konflikti ob združevanju in jih reši (če je rerere.enabled
nastavljeno na true
, se to izvede samodejno).
Obstajajo tudi podukazi, s katerimi lahko vidite, kaj bo zabeleženo, izbrišete določeno rešitev iz predpomnilnika ali počistite celoten predpomnilnik.
Rerere bomo podrobneje obravnavali v Rerere.
Označevanje vaših izdaj
Ko se odločite za izdajo, boste verjetno želeli dodeliti oznako, da boste lahko to izdajo ustvarili kadarkoli v prihodnosti. Novo oznako lahko ustvarite, kot je opisano v poglavju Osnove Git. Če se odločite podpisati oznako kot vzdrževalec, je lahko postopek označevanja videti nekako takole:
$ git tag -s v1.5 -m 'my signed 1.5 tag'
You need a passphrase to unlock the secret key for
user: "Scott Chacon <schacon@gmail.com>"
1024-bit DSA key, ID F721C45A, created 2009-02-09
Če podpišete svoje oznake, se lahko pojavijo težave pri distribuciji javnega ključa PGP, ki se uporablja za podpisovanje vaših oznak.
Vzdrževalec projekta Git je to težavo rešil tako, da je svoj javni ključ vključil kot blob v repozitoriju in nato dodal oznako, ki neposredno kaže na ta vsebino.
Kateri ključ želite, lahko ugotovite tako, da zaženete ukaz gpg --list-keys
:
$ gpg --list-keys
/Users/schacon/.gnupg/pubring.gpg
---------------------------------
pub 1024D/F721C45A 2009-02-09 [expires: 2010-02-09]
uid Scott Chacon <schacon@gmail.com>
sub 2048g/45D02282 2009-02-09 [expires: 2010-02-09]
Nato lahko ključ neposredno uvozite v Gitovo bazo tako, da ga izvozite in pretakate skozi git hash-object
, ki napiše nov blob s temi vsebinami v Git in vrne SHA-1 bloba:
$ gpg -a --export F721C45A | git hash-object -w --stdin
659ef797d181633c87ec71ac3f9ba29fe5775b92
Zdaj, ko imate vsebino ključa v Gitu, lahko ustvarite oznako, ki nanjo neposredno kaže, tako da navedete novo vrednost SHA-1, ki vam jo je dal ukaz hash-object
:
$ git tag -a maintainer-pgp-pub 659ef797d181633c87ec71ac3f9ba29fe5775b92
Če zaženete git push --tags
, se bo oznaka maintainer-pgp-pub
delila z vsemi.
Če želi kdo preveriti oznako, lahko vaš ključ PGP neposredno uvozi tako, da povleče blob neposredno iz baze podatkov in ga uvozi v GPG:
$ git show maintainer-pgp-pub | gpg --import
S tem ključem lahko preverijo tudi vse vaše podpisane oznake.
Poleg tega lahko z navodili v sporočilu oznake zagon git show <tag>
uporabnikom ponudi bolj specifična navodila za preverjanje oznake.
Ustvarjanje številke gradnje
Ker Git nima za vsako potrditev monotono naraščajočih številk, kot so v123
ali enakovredne, lahko za ime, ki je berljivo za ljudi in ki pripada potrditvi, uporabite git describe
na tej potrditvi.
V odzivu Git generira niz, ki sestoji iz imena najnovejše označene potrditve, ki se pojavi pred to potrditvijo, sledi število potrditev od te označene potrditve, nato pa delna vrednost SHA-1 potrditve, ki se opisuje (predpona g
pomeni Git):
$ git describe master
v1.6.2-rc1-20-g8c5b85c
Na ta način lahko izvozite posnetek ali ga sestavite in mu dodelite ime, ki ga ljudje razumejo.
Dejansko, če Git zgradite iz izvorne kode, ki jo prenesete iz repozitorija Git, vam git --version
da nekaj, kar je videti tako.
Če opišete potrditev, ki ste jo neposredno označili, vam preprosto prikaže ime oznake.
Privzeto ukaz git describe
zahteva anotirane oznake (oznake, ustvarjene z zastavico -a
ali -s
); če želite izkoristiti tudi enostavne (ne-anotirane) oznake, dodajte ukazu možnost --tags
.
Ta niz lahko uporabite tudi kot cilj ukaza git checkout
ali git show
, vendar je odvisen od okrajšane vrednosti SHA-1 na koncu, zato morda ne bo za vedno veljaven.
Na primer, jedro Linuxa se je nedavno preusmerilo iz 8 na 10 znakov, da bi zagotovilo enoličnost objekta SHA-1, zato so bili starejši izpisi imen git describe
neveljavni.
Priprava izdaje
Sedaj želite objaviti gradnjo.
Ena od stvari, ki jo boste želeli narediti, je ustvariti arhiv najnovejše slike vaše kode za tiste uboge duše, ki ne uporabljajo Gita.
Ukaz za to je git archive
:
$ git archive master --prefix='project/' | gzip > `git describe master`.tar.gz
$ ls *.tar.gz
v1.6.2-rc1-20-g8c5b85c.tar.gz
Če nekdo odpre tisti stisnjeni arhiv tar (angl. tarball), dobi najnovejši posnetek vašega projekta pod direktorijem project
.
Na podoben način pa lahko ustvarite tudi arhiv zip, vendar tako, da daste --format=zip
kot možnost ukazu git archive
:
$ git archive master --prefix='project/' --format=zip > `git describe master`.zip
Zdaj imate lep stisnjen arhiv tar in arhiv zip vaše projektne izdaje, ki ju lahko naložite na svojo spletno stran, ali pošljete ljudem po e-pošti.
Kratek dnevnik (angl. shortlog)
Čas je, da pošljete elektronsko pošto svojemu seznamu prejemnikov, ki želijo vedeti, kaj se dogaja v vašem projektu.
Lep način hitrega pridobivanja vrste sprememb, ki so bile dodane v vaš projekt od zadnje objave ali e-pošte, je uporaba ukaza git shortlog
.
Povzame vse potrditve v določenem obsegu; na primer, naslednje vam da povzetek vseh potrditev od zadnje objave, če je bila vaša zadnja objava poimenovana v1.0.1
:
$ git shortlog --no-merges master --not v1.0.1
Chris Wanstrath (6):
Add support for annotated tags to Grit::Tag
Add packed-refs annotated tag support.
Add Grit::Commit#to_patch
Update version and History.txt
Remove stray `puts`
Make ls_tree ignore nils
Tom Preston-Werner (4):
fix dates in history
dynamic version method
Version bump to 1.0.2
Regenerated gemspec for version 1.0.2
Dobite čisti povzetek vseh potrditev od v1.0.1
, združen po avtorju, ki ga lahko pošljete po elektronski pošti na svoj seznam prejemnikov.