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.
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 masterAli če želite takoj nanjo tudi preklopiti, lahko uporabite možnost checkout -b:
$ git checkout -b sc/ruby_client masterSedaj 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.
Č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.
Č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.patchTo 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.
Č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 <[email protected]>
Date: Sun, 6 Apr 2008 10:17:23 -0700
Subject: [PATCH 1/2] Add limit to log function
Limit log functionality to the first 20To 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 functionVidite 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 <[email protected]>
AuthorDate: Sun Apr 6 10:17:23 2008 -0700
Commit: Scott Chacon <[email protected]>
CommitDate: Thu Apr 9 09:19:06 2009 -0700
Add limit to log function
Limit log functionality to the first 20Informacije 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 allTo 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.
Č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.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 <[email protected]>
Date: Fri Oct 24 09:53:59 2008 -0700
See if this helps the gem
commit 7482e0d16d04bea79d0dba8988cc78df655f16a0
Author: Scott Chacon <[email protected]>
Date: Mon Oct 22 19:38:36 2008 -0700
Update gemspec to hopefully work betterDa 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 masterTa 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 36c7dbali 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...contribTa 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.
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.
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.
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).
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.
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.
Č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:
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.
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:
Č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:
Sedaj lahko odstranite svojo tematsko vejo in opustite potrditve, ki jih niste želeli povleči.
Č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 trueSedaj, 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 ch07-git-tools.asc.
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 ch02-git-basics-chapter.asc. Č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 <[email protected]>"
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 <[email protected]>
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
659ef797d181633c87ec71ac3f9ba29fe5775b92Zdaj, 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 --importS 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.
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-g8c5b85cNa 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.
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`.zipZdaj 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.
Č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.2Dobite č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.