Git
Chapters ▾ 2nd Edition

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
Slika 72. Zgodovina z več tematskimi vejami
Po združitvi tematske veje
Slika 73. 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).

Pred združitvijo tematske veje
Slika 74. Pred združitvijo tematske veje
Po združitvi tematske veje
Slika 75. Po združitvi tematske veje
Po objavi projekta
Slika 76. 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.

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
Slika 77. Upravljanje kompleksne serije vzporednih prispevanih tematskih vej

Č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
Slika 78. Združevanje prispevanih tematskih vej v dolgotrajne integracijske veje

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
Slika 79. Primer zgodovine pred izbiro najboljšega

Č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
Slika 80. Zgodovina po izbiri najboljše potrditve iz tematske veje

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.

scroll-to-top