Chapters ▾ 2nd Edition

5.3 Distributed Git - Die Beheer van 'n Projek (Maintaining a Project)

Die Beheer van 'n Projek (Maintaining a Project)

Benewens om te weet hoe om doeltreffend tot 'n projek by te dra, sal jy waarskynlik ook moet weet hoe om een te beheer. Dit kan bestaan uit die aanvaarding en toepassing van pleisters (patches) wat via format-patch gegenereer en aan jou gemail is, of die integrasie van veranderings in afgeleë takke (remote branches) vir bewaarplekke wat jy as remotes by jou projek gevoeg het. Of jy nou 'n kanonieke bewaarplek beheer of wil help deur pleisters te verifieer of goed te keur, jy moet weet hoe om werk te aanvaar op 'n manier wat die duidelikste is vir ander bydraers en volhoubaar is vir jou oor die lang termyn.

Werken in Onderwerp-takke (Working in Topic Branches)

Wanneer jy daaraan dink om nuwe werk te integreer, is dit oor die algemeen 'n goeie idee om dit uit te probeer in 'n onderwerp-tak (topic branch) — 'n tydelike tak wat spesifiek gemaak is om daardie nuwe werk uit te probeer. Op hierdie manier is dit maklik om 'n pleister individueel te aanpas en dit te los as dit nie werk nie, totdat jy tyd het om daarna terug te keer. As jy 'n eenvoudige taknaam skep gebaseer op die tema van die werk wat jy gaan probeer, soos ruby_client of iets soortgelyks beskrywend, kan jy dit maklik onthou as jy dit vir 'n rukkie moet laat vaar en later terugkeer. Die instandhouer (maintainer) van die Git-projek is ook geneig om hierdie takke in naamruimtes (namespaces) te plaas — soos sc/ruby_client, waar sc kort is vir die persoon wat die werk bygedragen het. Soos jy sal onthou, kan jy die tak gebaseer op jou master tak so skep:

$ git branch sc/ruby_client master

Of, as jy ook dadelik daarna wil oorskakel, kan jy die checkout -b opsie gebruik:

$ git checkout -b sc/ruby_client master

Nou is jy gereed om die bygedrae werk wat jy ontvang het by hierdie onderwerp-tak te voeg en te bepaal of jy dit in jou langertermyn-takke wil insmelt.

Pleisters vanaf E-pos Toepassing (Applying Patches from Email)

As jy 'n pleister oor e-pos ontvang wat jy in jou projek moet integreer, moet jy die pleister in jou onderwerp-tak toepas om dit te evalueer. Daar is twee maniere om 'n gemailde pleister toe te pas: met git apply of met git am.

Toepassing van 'n Pleister met apply (Applying a Patch with apply)

As jy die pleister ontvang het van iemand wat dit met git diff of een of ander variasie van die Unix diff opdrag gegenereer het (wat nie aanbeveel word nie; sien die volgende afdeling), kan jy dit toepas met die git apply opdrag. Aannemende dat jy die pleister by /tmp/patch-ruby-client.patch gestoor het, kan jy die pleister so toepas:

$ git apply /tmp/patch-ruby-client.patch

Dit wysig die lêers in jou werkgids (working directory). Dit is amper identies aan die uitvoering van 'n patch -p1 opdrag om die pleister toe te pas, alhoewel dit meer paranoïed is en minder vae ooreenkomste (fuzzy matches) as patch aanvaar. Dit hanteer ook lêerbyvoegings, -verwyderings en -hernoemings as dit in die git diff formaat beskryf word, wat patch nie sal doen nie. Ten slotte is git apply 'n “pas alles toe of breek alles af” model waar óf alles toegepas word óf niks, terwyl patch pleisterlêers gedeeltelik kan toepas en jou werkgids in 'n vreemde toestand kan laat. git apply is oor die algemeen baie meer konserwatief as patch. Dit sal nie 'n vaslegging (commit) vir jou skep nie — nadat dit uitgevoer is, moet jy die veranderings wat ingestel is handmatig voorberei (stage) en vaslê.

Jy kan ook git apply gebruik om te sien of 'n pleister skoon toepas voordat jy dit werklik probeer toepas — jy kan git apply --check met die pleister uitvoer:

$ git apply --check 0001-see-if-this-helps-the-gem.patch
error: patch failed: ticgit.gemspec:1
error: ticgit.gemspec: patch does not apply

As daar geen afvoer is nie, behoort die pleister skoon toe te pas. Hierdie opdrag sluit ook af met 'n nie-nul status as die kontrole misluk, sodat jy dit in skrifte kan gebruik as jy wil.

Toepassing van 'n Pleister met am (Applying a Patch with am)

As die bydraer 'n Git-gebruiker is en goed genoeg was om die format-patch opdrag te gebruik om hul pleister te genereer, is jou werk makliker omdat die pleister outeurinligting en 'n vasleggingsboodskap vir jou bevat. As jy kan, moedig jou bydraers aan om format-patch in plaas van diff te gebruik om pleisters vir jou te genereer. Jy behoort slegs git apply te hoef te gebruik vir erfenis-pleisters (legacy patches) en dinge soos dit.

Om 'n pleister wat deur format-patch gegenereer is toe te pas, gebruik jy git am (die opdrag is am genoem aangesien dit gebruik word om "a reeks pleisters van 'n posbus af toe te pas" — apply a series of patches from a mailbox). Tegnies is git am gebou om 'n mbox-lêer te lees, wat 'n eenvoudige, gewone-teksformaat is om een of meer e-posboodskappe in een tekslêer te stoor. Dit lyk min of meer so:

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

Dit is die begin van die afvoer van die git format-patch opdrag wat jy in die vorige afdeling gesien het; dit verteenwoordig ook 'n geldige mbox-e-posformaat. As iemand jou die pleister behoorlik gemail het deur git send-email te gebruik, en jy laai dit af in 'n mbox-formaat, dan kan jy git am na daardie mbox-lêer wys, en dit sal begin om al die pleisters wat dit sien toe te pas. As jy 'n poskliënt (mail client) laat loop wat verskeie e-posse in mbox-formaat kan stoor, kan jy hele pleisterreekse in 'n lêer stoor en dan git am gebruik om dit een op 'n keer toe te pas.

As iemand egter 'n pleisterlêer wat via format-patch gegenereer is op 'n kaartjiesisteem (ticketing system) of iets soortgelyks opgelaai het, kan jy die lêer plaaslik stoor en dan daardie lêer wat op jou skyf gestoor is aan git am deurgee om dit toe te pas:

$ git am 0001-limit-log-function.patch
Applying: Add limit to log function

Jy kan sien dat dit skoon toegepas is en outomaties die nuwe vaslegging vir jou geskep het. Die outeurinligting word geneem uit die e-pos se From en Date opskrifte (headers), en die boodskap van die vaslegging word geneem uit die Subject en liggaam (voor die pleister) van die e-pos. Byvoorbeeld, as hierdie pleister toegepas is vanaf die mbox-voorbeeld hierbo, sou die gegenereerde vaslegging so iets so lyk:

$ 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

Die Commit inligting dui die persoon aan wat die pleister toegepas het en die tyd wat dit toegepas is. Die Author inligting is die individu wat oorspronklik die pleister geskep het en wanneer dit oorspronklik geskep is.

Maar dit is moontlik dat die pleister nie skoon sal toepas nie. Miskien het jou hooftak te ver afgewyk van die tak waarvan die pleister gebou is, of die pleister hang af van 'n ander pleister wat jy nog nie toegepas het nie. In daardie geval sal die git am proses misluk en jou vra wat jy wil doen:

$ 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".

Hierdie opdrag plaas konflikmerkers in enige lêers waarmee dit kwessies het, baie soos 'n gekonflikteerde saamsmeltings- (merge) of herbaserings- (rebase) operasie. Jy los hierdie kwessie op dieselfde manier op — wysig die lêer om die konflik op te los, voorberei (stage) die nuwe lêer, en voer dan git am --resolved uit om na die volgende pleister voort te gaan:

$ (fix the file)
$ git add ticgit.gemspec
$ git am --resolved
Applying: See if this helps the gem

As jy wil hê Git moet 'n bietjie meer intelligent probeer om die konflik op te los, kan jy 'n -3 opsie daaraan deurgee, wat Git 'n drierigting-saamsmelting (three-way merge) laat probeer. Hierdie opsie is nie by verstek aan nie omdat dit nie werk nie as die vaslegging wat die pleister sê dit op gebaseer is, nie in jou bewaarplek is nie. As jy wel daardie vaslegging het — as die pleister gebaseer was op 'n openbare vaslegging — dan is die -3 opsie oor algemeen baie slim oor die toepassing van 'n gekonflikteerde pleister:

$ 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.

In hierdie geval, sonder die -3 opsie sou die pleister as 'n konflik beskou gewees het. Aangesien die -3 opsie gebruik is, het die pleister skoon toegepas.

As jy 'n aantal pleisters van 'n mbox toepas, kan jy ook die am opdrag in interaktiewe modus uitvoer, wat stop by elke pleister wat dit vind en vra of jy dit wil toepas:

$ 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

Dit is gaaf as jy 'n aantal pleisters gestoor het, omdat jy eers die pleister kan bekyk as jy nie onthou wat dit is nie, of nie die pleister toepas as jy dit reeds gedoen het nie.

Wanneer al die pleisters vir jou onderwerp toegepas en vasgelê is in jou tak, kan jy kies óf en hoe om dit in 'n langlopende tak te integreer.

Uitcheck van Afgeleë Takke (Checking Out Remote Branches)

As jou bydrag gekom het van 'n Git-gebruiker wat hul eie bewaarplek opgestel het, 'n aantal veranderings daarin gepush het, en toe vir jou die URL na die bewaarplek en die naam van die afgeleë tak waarin die veranderings is gestuur het, kan jy hulle as 'n remote byvoeg en saamsmeltings plaaslik doen.

Byvoorbeeld, as Jessica vir jou 'n e-pos stuur waarin sy sê dat sy 'n wonderlike nuwe kenmerk in die ruby-client tak van haar bewaarplek het, kan jy dit toets deur die remote by te voeg en daardie tak plaaslik uit te check:

$ git remote add jessica https://github.com/jessica/myproject.git
$ git fetch jessica
$ git checkout -b rubyclient jessica/ruby-client

As sy jou later weer e-pos met 'n ander tak wat 'n ander wonderlike kenmerk bevat, kan jy direk fetch en checkout omdat jy reeds die remote-opstelling het.

Dit is die nuttigste as jy konsekwent met 'n persoon werk. As iemand net af en toe 'n enkele pleister het om by te dra, dan is dit dalk minder tydrowend om dit oor e-pos te aanvaar as om te vereis dat almal hul eie bediener laat loop en voortdurend remotes moet byvoeg en verwyder om 'n paar pleisters te kry. Dit is ook onwaarskynlik dat jy honderde remotes wil hê, elk vir iemand wat net 'n pleister of twee bydra. Skrifte en gehoste dienste kan dit egter makliker maak — dit hang grootliks af van hoe jy ontwikkel en hoe jou bydraers ontwikkel.

Die ander voordeel van hierdie benadering is dat jy ook die geskiedenis van die vasleggings kry. Alhoewel jy dalk wettige saamsmeltingskwessies kan hê, weet jy waar in jou geskiedenis hul werk gebaseer is; 'n behoorlijke drierigting-saamsmelting is die verstek eerder as om 'n -3 te moet verskaf en te hoop dat die pleister gegenereer is van 'n openbare vaslegging waartoe jy toegang het.

As jy nie konsekwent met 'n persoon werk nie, maar tog op hierdie manier van hulle wil pull, kan jy die URL van die afgeleë bewaarplek aan die git pull opdrag verskaf. Dit doen 'n eenmalige pull en stoor nie die URL as 'n afgeleë verwysing nie:

$ git pull https://github.com/onetimeguy/project
From https://github.com/onetimeguy/project
 * branch            HEAD       -> FETCH_HEAD
Merge made by the 'recursive' strategy.

Bepaling van Wat Ingestel Is (Determining What Is Introduced)

Nou het jy 'n onderwerp-tak wat bijgedragen werk bevat. Op hierdie punt kan jy bepaal wat jy daarmee wil doen. Hierdie afdeling hersien 'n paar opdragte sodat jy kan sien hoe jy dit kan gebruik om presies te hersien wat jy sal instel as jy dit in jou hooftak insmelt.

Dit is dikwels nuttig om 'n oorsig te kry van al die vasleggings wat in hierde tak is, maar wat nie in jou master tak is nie. Jy kan vasleggings in die master tak uitsluit deur die --not opsie voor die taknaam by te voeg. Dit doen dieselfde ding as die master..contrib formaat wat ons vroeër gebruik het. Byvoorbeeld, as jou bydraer vir jou twee pleisters stuur en jy skep 'n tak genaamd contrib en het daardie pleisters daar toegepas, kan jy dit uitvoer:

$ 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

Om te sien watter veranderings elke vaslegging instel, onthou dat jy die -p opsie aan git log kan deurgee en dit sal die verskil (diff) wat by elke vaslegging ingestel is, aanheg.

Om 'n volledige diff te sien van wat sal gebeur as jy hierdie onderwerp-tak met 'n ander tak insmelt, moet jy dalk 'n vreemde truuk gebruik om die korrekte resultate te kry. Jy dink dalk om dit uit te voer:

$ git diff master

Hierdie opdrag gee vir jou 'n diff, maar dit kan misleidend wees. As jou master tak vorentoe beweeg het sedert jy die onderwerp-tak daarvan geskep het, dan sal jy oënskynlik vreemde resultate kry. Dit gebeur omdat Git die momentopnames van die laaste vaslegging van die onderwerp-tak waarop jy is en die momentopname van die laaste vaslegging op die master tak direk vergelyk. Byvoorbeeld, as jy 'n reël in 'n lêer op die master tak bygevoeg het, sal 'n direkte vergelyking van die momentopnames lyk of die onderwerp-tak daardie reël gaan verwyder.

As master 'n direkte voorouer van jou onderwerp-tak is, is dit nie 'n probleem nie; maar as die twee geskiedenisse afgewyk het, sal die diff lyk of jy al die nuwe dinge in jou onderwerp-tak byvoeg en alles wat uniek is aan die master tak verwyder.

Wat jy regtig wil sien, is die veranderings wat by die onderwerp-tak gevoeg is — die werk wat jy sal instel as jy hierdie tak met master insmelt. Jy doen dit deur te hê dat Git die laaste vaslegging op jou onderwerp-tak vergelyk met die eerste gemeenskaplike voorouer wat dit met die master tak het.

Tegnies kan jy dit doen deur die gemeenskaplike voorouer eksplisiet uit te vind en dan jou diff daarop uit te voer:

$ git merge-base contrib master
36c7dba2c95e6bbb78dfa822519ecfec6e1ca649
$ git diff 36c7db

of, meer bondig:

$ git diff $(git merge-base contrib master)

Neltemin is nie een van dié besonder gerieflik nie, so Git bied 'n ander kortpad om dieselfde ding te doen: die driedubbelpunt-sintaksis. In die konteks van die git diff opdrag, kan jy drie punte na 'n ander tak plaas om 'n diff te doen tussen die laaste vaslegging van die tak waarop jy is en sy gemeenskaplike voorouer met 'n ander tak:

$ git diff master...contrib

Hierdie opdrag wys jou slegs die werk wat jou huidige onderwerp-tak ingestel het sedert sy gemeenskaplike voorouer met master. Dit is 'n baie nuttige sintaksis om te onthou.

Integrasie van Bygedragen Werk (Integrating Contributed Work)

Wanneer al die werk in jou onderwerp-tak gereed is om in 'n meer hooflyntak geïntegreer te word, is die vraag hoe om dit te doen. Verder, watter algemene werkvloei wil jy gebruik om jou projek te beheer? Jy het 'n aantal keuses, so ons sal 'n paar van hulle dek.

Saamsmeltingswerkvloeie (Merging Workflows)

Een basiese werkvloei is om eenvoudig al daardie werk direk in jou master tak in te smelt. In hierdie scenario het jy 'n master tak wat basies stabiele kode bevat. Wanneer jy werk in 'n onderwerp-tak het wat jy dink jy voltooi het, of werk wat iemand anders bygedragen het en jy geverifieer het, smelt jy dit in jou master tak in, vee daardie pas-saamgesmelte onderwerp-tak uit, en herhaal.

Byvoorbeeld, as ons 'n bewaarplek het met werk in twee takke genaamd ruby_client en php_client wat lyk soos Geskiedenis met verskeie onderwerp-takke, en ons smelt ruby_client gevolg deur php_client in, sal jou geskiedenis eindig om so te lyk soos Na 'n onderwerp-tak saamsmelting.

History with several topic branches
Figure 85. Geskiedenis met verskeie onderwerp-takke
After a topic branch merge
Figure 86. Na 'n onderwerp-tak saamsmelting

Dit is waarskynlijk die eenvoudigste werkvloei, maar dit kan moontlik problematies wees as jy te make het met groter of stabielere projecte waar jy regtig versigtig wil wees oor wat jy instel.

As jy 'n belangriker projek het, wil jy dalk 'n tweefase-saamsmeltingsiklus gebruik. In hierdie scenario het jy twee langlopende takke, master en develop, waarin jy bepaal dat master slegs opgedateer word wanneer 'n baie stabiele vrystelling (release) gesny word en alle nuwe kode in die develop tak geïntegreer word. Jy push albei hierdie takke gereeld na die openbare bewaarplek. Elke keer as jy 'n nuwe onderwerp-tak het om in te smelt (Voor 'n onderwerp-tak saamsmelting), smelt jy dit in develop in (Na 'n onderwerp-tak saamsmelting); dan, wanneer jy 'n vrystelling merk (tag), skuif jy master vinnig-vorentoe (fast-forward) na waar die nou-stabiele develop tak ook al is (Na 'n projekvrystelling).

Before a topic branch merge
Figure 87. Voor 'n onderwerp-tak saamsmelting
After a topic branch merge
Figure 88. Na 'n onderwerp-tak saamsmelting
After a project release
Figure 89. Na 'n projekvrystelling

Op hierdie manier, wanneer mense jou projek se bewaarplek kloon, kan hulle óf master uitcheck om die nuutste stabiele weergawe te bou en maklik daardie op datum te hou, óf hulle kan develop uitcheck, wat die meer nuutste inhoud is. Jy kan ook hierdie konsep uitbrei deur 'n integrate tak te hê waar al die werk saamgesmelt word. Dan, wanneer die kodetal op daardie tak stabiel is en toetse slaag, smelt jy dit in 'n develop tak in; en wanneer dit homself vir 'n rukkie as stabiel bewys het, skuif jy jou master tak vinnig-vorentoe.

Grootskaalse Saamsmeltingswerkvloeie (Large-Merging Workflows)

Die Git-projek het vier langlopende takke: master, next, en seen (voorheen 'pu' — voorgestelde opdaterings / proposed updates) vir nuwe werk, en maint vir onderhoudsterugplaatsings (maintenance backports). Wanneer nuwe werk deur bydraers ingestel word, word dit versamel in onderwerp-takke in die instandhouer se bewaarplek op 'n manier soortgelyk aan wat ons beskryf het (sien Bestuur van 'n komplekse reeks parallelle bygedragen onderwerp-takke). Op hierdie punt word die onderwerpe geëvalueer om te bepaal of hulle veilig en gereed is vir verbruik of dat hulle meer werk nodig het. As hulle veilig is, word hulle in next ingesmelt, en daardie tak word opgestup sodat almal die geïntegreerde onderwerpe kan probeer.

Managing a complex series of parallel contributed topic branches
Figure 90. Bestuur van 'n komplekse reeks parallelle bygedragen onderwerp-takke

As die onderwerpe steeds werk nodig het, word hulle in plaas daarvan in seen ingesmelt. Wanneer vasgestel word dat hulle heeltemal stabiel is, word die onderwerpe heringesmelt in master. Die next en seen takke word dan herbou vanaf die master. Dit beteken master beweeg byna altyd vorentoe, next word af en toe gerebase, en seen word selfs meer gereeld gerebase:

Merging contributed topic branches into long-term integration branches
Figure 91. Saamsmelting van bygedragen onderwerp-takke in langtermyn-integrasietakke

Wanneer 'n onderwerp-tak uiteindelik in master ingesmelt is, word dit van die bewaarplek verwyder. Die Git-projek het ook 'n maint tak wat afgetak is van die laaste vrystelling om teruggeplaatste pleisters te voorsien ingeval 'n onderhoudsvrystelling vereis word. Dus, wanneer jy die Git-beheerplek kloon, het jy vier takke wat jy kan uitcheck om die projek in verskillende stadia van ontwikkeling te evalueer, afhangende van hoe nuut jy wil wees of hoe jy wil bydra; en die instandhouer het 'n gestructureerde werkvloei om hulle te help om nuwe bydraes te keur. Die Git-projek se werkvloei is gespesialiseerd. Om dit duidelik te verstaan, kan jy na die Git Maintainer’s guide kyk.

Herbasering en Cherry-Picking Werkvloeie (Rebasing and Cherry-Picking Workflows)

Ander instandhouers verkies om bygedragen werk bo-op hul master tak te rebase of te cherry-pick, eerder as om dit in te smelt, om 'n meestal lineêre geskiedenis te behou. Wanneer jy werk in 'n onderwerp-tak het en bepaal het dat jy dit wil integreer, beweeg jy na daardie tak en voer die rebase opdrag uit om die veranderings bo-op jou huidige master (of develop, ensovoorts) tak te herbou. As dit goed werk, kan jy jou master tak vinnig-vorentoe stuur, en jy sal eindig met 'n lineêre projekgeskiedenis.

Die ander manier om ingestelde werk van een tak na 'n ander te skuif, is om dit te cherry-pick. 'n Cherry-pick in Git is soos 'n rebase vir 'n enkele vaslegging. Dit neem die pleister wat in 'n vaslegging ingestel is en probeer dit weer toepas op die tak waarop jy tans is. Dit is nuttig as jy 'n aantal vasleggings op 'n onderwerp-tak het en slegs een van hulle wil integreer, of as jy net een vaslegging op 'n onderwerp-tak het en verkies om dit te cherry-pick eerder as om rebase uit te voer. Byvoorbeeld, veronderstel jy het 'n projek wat so lyk:

Example history before a cherry-pick
Figure 92. Voorbeeldgeskiedenis voor 'n cherry-pick

As jy vaslegging e43a6 in jou master tak wil pull, kan jy uitvoer:

$ 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(-)

Dit trek dieselfde verandering in e43a6 ingestel af, maar jy kry 'n nuwe vaslegging SHA-1 waarde, omdat die toegepaste datum anders is. Nou lyk jou geskiedenis so:

History after cherry-picking a commit on a topic branch
Figure 93. Geskiedenis na die cherry-pick van 'n vaslegging op 'n onderwerp-tak

Nou kan jy jou onderwerp-tak verwyder en die vasleggings laat vaar wat jy nie in wou pull nie.

Rerere

As jy baie saamsmelt en rebase, of jy 'n langlopende onderwerp-tak beheer, het Git 'n kenmerk genaamd “rerere” wat kan help.

Rerere staan vir “reuse recorded resolution” (hergebruik opgeneemde resolusie) — dit is 'n manier om handmatige konflikoplossing te kort te sny. Wanneer rerere aangeskakel is, sal Git 'n stel voor- en na-beelde van suksesvolle saamsmeltings hou, en as dit opmerk dat daar 'n konflik is wat presies lyk soos een wat jy reeds opgelos het, sal dit net die regmaak van die laaste keer gebruik, sonder om jou daarmee te lastig te val.

Hierdie kenmerk kom in twee dele: 'n konfigurasie-instelling en 'n opdrag. Die konfigurasie-instelling is rerere.enabled, en dit is handig genoeg om in jou globale konfigurasie te plaas:

$ git config --global rerere.enabled true

Nou, wanneer jy ook al 'n saamsmelting doen wat konflikte oplos, sal die resolusie in die kas (cache) opgeneem word vir ingeval jy dit in die toekoms nodig het.

As jy moet, kan jy met die rerere-kas wisselwerking hê deur die git rerere opdrag te gebruik. Wanneer dit alleen aangeroep word, kontroleer Git sy databasis van resolusies en probeer 'n ooreenkoms vind met enige huidige saamsmeltingskonflikte en dit oplos (al word dit outomaties gedoen as rerere.enabled op true gestel is). Daar is ook subopdracks om te sien wat opgeneem sal word, om spesifieke resolusies uit die kas te wis, en om die hele kas skoon te maak. Ons sal rerere in meer detail dek in Rerere.

Merk van Jou Vrystellings (Tagging Your Releases)

Wanneer jy besluit het om 'n vrystelling te sny (cut a release), wil jy waarskynlik 'n merker (tag) toewys sodat jy daardie vrystelling op enige punt vorentoe kan herskep. Jy kan 'n nuwe merker skep soos bespreek in Git Basics. As jy besluit om die merker as die instandhouer te teken, kan die merking so iets so lyk:

$ 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

As jy wel jou merkers teken, het jy dalk die probleem om die publieke PGP-sleutel wat gebruik word om jou merkers te teken, te versprei. Die instandhouer van die Git-projek het hierdie kwessie opgelos deur hul publieke sleutel as 'n blob in die bewaarplek in te sluit en dan 'n merker by te voeg wat direk na daardie inhoud wys. Om dit te doen, kan jy uitvind watter sleutel jy wil hê deur gpg --list-keys uit te voer:

$ 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]

Dan kan jy die sleutel direk in die Git-databasis invoer deur dit te eksporteer en dit deur git hash-object te pyp, wat 'n nuwe blob met daardie inhoud in Git skryf en vir jou die SHA-1 van die blob teruggee:

$ gpg -a --export F721C45A | git hash-object -w --stdin
659ef797d181633c87ec71ac3f9ba29fe5775b92

Nou dat jy die inhoud van jou sleutel in Git het, kan jy 'n merker skep wat direk daarna wys deur die nuwe SHA-1 waarde te spesifiseer wat die hash-object opdrag vir jou gegee het:

$ git tag -a maintainer-pgp-pub 659ef797d181633c87ec71ac3f9ba29fe5775b92

As jy git push --tags uitvoer, sal die maintainer-pgp-pub merker met almal gedeel word. As iemand 'n merker wil verifieer, kan hulle jou PGP-sleutel direk invoer deur die blob direk uit die databasis te pull en dit in GPG in te voer:

$ git show maintainer-pgp-pub | gpg --import

Hulle kan daardie sleutel gebruik om al jou getekende merkers te verifieer. Ook, as jy instruksies in die merkerboodskap insluit, sal die uitvoering van git show <tag> jou in staat stel om die eindgebruiker meer spesifieke instruksies oor merkerverifikasie te gee.

Generering van 'n Bou-nommer (Generating a Build Number)

Omdat Git nie monotoon toenemende nommers soos 'v123' of die ekwivalent het om by elke vaslegging te pas nie, as jy 'n mensleesbare naam wil hê om by 'n vaslegging te pas, kan jy git describe op daardie vaslegging uitvoer. In reaksie daarop genereer Git 'n string wat bestaan uit die naam van die mees resente merker vroeër as daardie vaslegging, gevolg deur die aantal vasleggings sedert daardie merker, gevolg uiteindelik deur 'n gedeeltelijke SHA-1 waarde van die vaslegging wat beskryf word (voorafgegaan deur die letter "g" wat Git beteken):

$ git describe master
v1.6.2-rc1-20-g8c5b85c

Op hierdie manier kan jy 'n momentopname of bou (build) eksporteer en dit noem iets wat verstaanbaar is vir mense. Trouens, as jy Git bou vanaf bronkode gekloon uit die Git-bewaarplek, gee git --version vir jou iets wat so lyk. As jy 'n vaslegging beskryf wat jy direk gemerk het, gee dit vir jou eenvoudig die merikernaam.

By verstek vereis die git describe opdrag geannoteerde merkers (merkers geskep met die -a of -s vlag); as jy ook wil voordeel trek uit liggewig (nie-geannoteerde) merkers, voeg die --tags opsie by die opdrag. Jy kan ook hierdie string gebruik as die teiken van 'n git checkout of git show opdrag, alhoewel dit staatmaak op die afgebeorte (abbreviated) SHA-1 waarde aan die einde, sodat dit dalk nie vir ewig geldig mag wees nie. Byvoorbeeld, die Linux-kern het onlangs gespring van 8 na 10 karakters om te verseker dat SHA-1 objekte uniek is, sodat ouer git describe afvoername ongeldig gemaak is.

Voorbereiding van 'n Vrystelling (Preparing a Release)

Nou wil jy 'n bou (build) vrystel. Een van die dinge wat jy wil doen, is om 'n argief van die nuutste momentopname van jou kode te skep vir daardie arme siele wat nie Git gebruik nie. Die opdrag om dit te doen is git archive:

$ git archive master --prefix='project/' | gzip > `git describe master`.tar.gz
$ ls *.tar.gz
v1.6.2-rc1-20-g8c5b85c.tar.gz

As iemand daardie teerbal (tarball) oopmaak, kry hulle die nuutste momentopname van jou projek onder 'n project gids. Jy kan ook 'n zip-argief op baie dieselfde manier skep, maar deur die --format=zip opsie aan git archive te gee:

$ git archive master --prefix='project/' --format=zip > `git describe master`.zip

Jy het nou 'n mooi teerbal en 'n zip-argief van jou projekvrystelling wat jy na jou webwerf kan oplaai of aan mense kan e-pos.

Die Kortlog (The Shortlog)

Dis tyd om jou poslys van mense wat wil weet wat in jou projek gebeur, te e-pos. 'n Goeie manier om vinnig 'n soort veranderingslogboek (changelog) te kry van wat by jou projek gevoeg is sedert jou laaste vrystelling of e-pos, is om die git shortlog opdrag te gebruik. Dit vat al die vasleggings in die reeks wat jy dit gee, saam; die volgende gee jou byvoorbeeld 'n opsomming van al die vasleggings sedert jou laaste vrystelling, as jou laaste vrystelling v1.0.1 geheet het:

$ 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

Jy kry 'n skoon opsomming van al die vasleggings sedert v1.0.1, gegroepeer volgens outeur, wat jy na jou lys kan e-pos.