5.2 Distributed Git - Bydrae tot 'n Projek (Contributing to a Project)

Voordat ons na die spesifieke gebruikscenarios begin kyk, is hier 'n vinnige nota oor vasleggingsboodskappe. Om 'n goeie riglyn vir die skep van vasleggings te hê en daarby te hou, maak dit 'n lot makliker om met Git te werk en met ander saam te werk. Die Git-projek voorsien 'n dokument wat 'n aantal goeie wenke uiteensit vir die skep van vasleggings om pleisters van in te dien — jy kan dit lees in die Git-bronkode in die Documentation/SubmittingPatches lêer.

Eerstens moet jou submissies geen witruimtefoute bevat nie. Git bied 'n maklike manier om hiervoor te kontroleer — voordat jy vaslê (commit), voer git diff --check uit, wat moontlike witruimtefoute identifiseer en dit vir jou lys.

As jy daardie opdrag voor vaslegging uitvoer, kan jy sê of jy op die punt staan om witruimtekwessies vas te lê wat ander ontwikkelaars kan irriteer.

Probeer dan om elke vaslegging 'n logies afsonderlike veranderingset (changeset) te maak. As jy kan, probeer om jou veranderings verteerbaar te maak — moenie vir 'n hele weke-eind op vyf verskillende kwessies kodeer en dit dan alles as een massiewe vaslegging op Maandag indien nie. Selfs al lê jy nie gedurende die weke-eind vas nie, gebruik die voorbereidingsarea (staging area) op Maandag om jou werk op te splits in ten minste een vaslegging per kwessie, met 'n nuttige boodskap per vaslegging. As sommige van die veranderings dieselfde lêer wysig, probeer om git add --patch te gebruik om lêers gedeeltelik te voorberei (in detail gedek in Interaktiewe Voorbereiding (Interactive Staging)). Die projekmomentopname aan die punt van die tak is identies, ongeag of jy een vaslegging of vyf doen, solank al die veranderings op een of ander punt bygevoeg word, so probeer om dinge makliker te maak vir jou mede-ontwikkelaars wanneer hulle jou veranderings moet hersien.

Hierdie benadering maak dit ook makliker om een van die veranderingsette uit te trek of terug te rol (revert) indien jy dit later benodig. Herskryf van Geskiedenis (Rewriting History) beskryf 'n aantal nuttige Git-truuks vir die herskryf van geskiedenis en interaktiewe voorbereiding van lêers — gebruik hierdie gereedskap om te help om 'n skone en verstaanbare geskiedenis te vorm voordat jy die werk aan iemand anders stuur.

Die laaste ding om in gedagte te hou is die vasleggingsboodskap. Om die gewoonte aan te leer om kwaliteitsvasleggingsboodskappe te skep, maak die gebruik van en samewerking met Git 'n lot makliker. As 'n algemene reël moet jou boodskappe begin met 'n enkele reël wat nie meer as ongeveer 50 karakters is nie en die veranderingset bondig beskryf, gevolg deur 'n leë reël, gevolg deur 'n meer gedetailleerde verduideliking. Die Git-projek vereis dat die meer gedetailleerde verduideliking jou motivering vir die verandering insluit en die implementering daarvan kontrasteer met vorige gedrag — dit is 'n goeie riglyn om te volg. Skryf jou vasleggingsboodskap in die gebiedende wys (imperative): "Fix bug" en nie "Fixed bug" of "Fixes bug" nie. Hier is 'n sjabloon wat jy kan volg, wat ons lig aangepas het vanaf een oorspronklik geskryf deur Tim Pope:

As al jou vasleggingsboodskappe hierdie model volg, sal dinge vir jou en die ontwikkelaars met wie jy saamwerk baie makliker wees. Die Git-projek het goed geformatteerde vasleggingsboodskappe — probeer om git log --no-merges daar uit te voer om te sien hoe 'n mooi geformatteerde projekvasleggingsgeskiedenis lyk.

Die eenvoudigste opstelling wat jy waarskynlik sal teëkom, is 'n beslote projek met een of twee ander ontwikkelaars. “Beslote” in hierdie konteks beteken geslote bronkode — nie toeganklik vir die buitewêreld nie. Jy en die ander ontwikkelaars het almal push-toegang tot die bewaarplek (repository).

In hierdie omgewing kan jy 'n werkvloei volg wat soortgelyk is aan wat jy dalk sou doen wanneer jy Subversion of 'n ander gesentraliseerde stelsel gebruik. Jy kry steeds die voordele van dinge soos vanlyn vaslegging en baie eenvoudiger vertakking en saamsmelting, maar die werkvloei kan baie dieselfde wees; die belangrikste verskil is dat saamsmeltings aan die kliëntkant plaasvind eerder as op die bediener ten tyde van vaslegging. Kom ons kyk hoe dit kan lyk wanneer twee ontwikkelaars begin saamwerk met 'n gedeelde bewaarplek. Die eerste ontwikkelaar, John, kloon die bewaarplek, maak 'n verandering, en lê plaaslik vas (commits). Die protokolboodskappe is in hierdie voorbeelde met …​ vervang om hulle ietwat te verkort.

Die tweede ontwikkelaar, Jessica, doen dieselfde ding — kloon die bewaarplek en lê 'n verandering vas:

Nou push Jessica haar werk na die bediener, wat heeltemal goed werk:

Die laaste reël van die afvoer hierbo toon 'n nuttige terugkeerboodskap van die push-operasie. Die basiese formaat is <oldref>..<newref> fromref → toref, waar oldref die ou verwysing beteken, newref beteken die nuwe verwysing, fromref is die naam van die plaaslike verwysing wat gepush word, en toref is die naam van die afgeleë verwysing wat opgedateer word. Jy sal soortgelyke afvoer soos hierdie hieronder in die besprekings sien, so om 'n basiese idee van die betekenis te hê, sal help om die verskillende toestande van die bewaarplekke te verstaan. Meer besonderhede is beskikbaar in die dokumentasie vir git-push.

Voortsettend met hierdie voorbeeld, maak John kort daarna 'n paar veranderings, lê dit vas in sy plaaslike bewaarplek, en probeer dit na dieselfde bediener push:

In hierdie geval misluk John se push as gevolg van Jessica se vroeër push van haar veranderings. Dit is veral belangrik om te verstaan as jy gewoond is aan Subversion, omdat jy sal merk dat die twee ontwikkelaars nie dieselfde lêer gewysig het nie. Alhoewel Subversion outomaties so 'n saamsmelting op die bediener doen as verskillende lêers gewysig word, moet jy met Git eers die vasleggings plaasliik saamsmelt. Met ander woorde, John moet eers Jessica se stroomopwaartse veranderings afhaal (fetch) en dit in sy plaaslike bewaarplek insmelt voordat hy toegelaat sal word om te push.

As 'n eerste stap haal John Jessica se werk af (dit haal slegs Jessica se stroomopwaartse werk af, dit smelt dit nog nie in John se werk in nie):

Op hierdie punt lyk John se plaaslike bewaarplek so iets soos dit:

Nou kan John Jessica se werk wat hy afgehaal het, in sy eie plaaslike werk insmelt:

Solank daardie plaaslike saamsmelting glad verloop, sal John se opgedateerde geskiedenis nou so lyk:

Op hierdie punt wil John dalk hierdie nuwe kode toets om seker te maak dat niks van Jessica se werk enige van syne beïnvloed nie en, solank alles goed lyk, kan hy uiteindelik die nuwe saamgesmelte werk opstuur na die bediener:

Ten slotte sal John se vasleggingsgeskiedenis so lyk:

Intussen het Jessica 'n nuwe onderwerp-tak genaamd issue54 geskep, en drie vasleggings op daardie tak gemaak. Sy het nog nie John se veranderings afgehaal nie, so haar vasleggingsgeskiedenis lyk so:

Skielik verneem Jessica dat John nuwe werk na die bediener gepush het en sy wil daarna kyk, sodat sy al die nuwe inhoud van die bediener kan afhaal wat sy nog nie het nie met:

Dit trek die werk af wat John intussen opgestuur het. Jessica se geskiedenis lyk nou so:

Jessica dink haar onderwerp-tak is gereed, maar sy wil weet watter deel van John se afgehaalde werk sy in haar werk moet insmelt sodat sy kan push. Sy voer git log uit om uit te vind:

Die issue54..origin/master sintaksis is 'n log-filter wat Git vra om slegs daardie vasleggings te vertoon wat op laasgenoemde tak is (in hierdie geval origin/master) en wat nie op die eerste tak is nie (in hierdie geval issue54). Ons sal hierdie sintaksis in detail dek in Vasleggingsreekse (Commit Ranges).

Uit bogenoemde afvoer kan ons sien dat daar 'n enkele vaslegging is wat John gemaak het wat Jessica nie in haar plaaslike werk ingesmelt het nie. As sy origin/master insmelt, is dit die enkele vaslegging wat haar plaaslike werk sal wysig.

Nou kan Jessica haar onderwerp-werk in haar master tak insmelt, John se werk (origin/master) in haar master tak insmelt, en dan weer terug push na die bediener toe.

Eerstens (nadat sy al die werk op haar issue54 onderwerp-tak vasgelê het), skakel Jessica terug na haar master tak ter voorbereiding vir die integrasie van al hierdie werk:

Jessica kan óf origin/master óf issue54 eerste insmelt — hulle is albei stroomop, dus maak die volgorde nie saak nie. Die eindmomentopname behoort identies te wees, ongeag watter volgorde sy kies; slegs die geskiedenis sal verskil. Sy kies om die issue54 tak eerste in te smelt:

Geen probleme kom voor nie; soos jy kan sien was dit 'n eenvoudige vinnig-vorentoe saamsmelting (fast-forward merge). Jessica voltooi nou die plaaslike saamsmeltingsproses deur John se vroeër afgehaalde werk wat in die origin/master tak sit, in te smelt:

Alles smelt skoon saam, en Jessica se geskiedenis lyk nou so:

Nou is origin/master bereikbaar vanaf Jessica se master tak, so sy behoort suksesvol te kan push (aannemende dat John nie intussen selfs meer veranderings gepush het nie):

Elke ontwikkelaar het 'n paar keer vasgelê en elkaars werk suksesvol saamgesmelt.

Dit is een van die eenvoudigste werkvloeie. Jy werk vir 'n rukkie (oor die algemeen in 'n onderwerp-tak), en smelt daardie werk in jou master tak in wanneer dit gereed is om geïntegreer te word. Wanneer jy daardie werk wil deel, haal jy af en smelt jou master uit origin/master in as dit verander het, en push uiteindelik na die master tak op die bediener. Die algemene volgorde is iets soos dit:

In hierdie volgende scenario sal jy kyk na bydraerols in 'n groter beslote groep. Jy sal leer hoe om te werk in 'n omgewing waar klein groepe aan kenmerke saamwerk, waarna daardie span-gebaseerde bydraes deur 'n ander party geïntegreer word.

Kom ons sê dat John and Jessica saam aan een kenmerk werk (noem dit “featureA”), terwyl Jessica en 'n derde ontwikkelaar, Josie, aan 'n tweede werk (sê nou, “featureB”). In hierdie geval gebruik die maatskappy 'n tipe integrasiebestuurder-werkvloei waar die werk van die individuele groepe slegs deur sekere ingenieurs geïntegreer word, en die master tak van die hoofbewaarplek slegs deur daardie ingenieurs opgedateer kan word. In hierdie scenario word al die werk in span-gebaseerde takke gedoen en later deur die integrators saamgetrek.

Kom ons volg Jessica se werkvloei terwyl sy aan haar twee kenmerke werk, en in parallel met twee verskillende ontwikkelaars in hierdie omgewing saamwerk. Aannemende dat sy reeds haar bewaarplek gekloon het, besluit sy om eerste aan featureA te werk. Sy skep 'n nuwe tak vir die kenmerk en doen 'n bietjie werk daaraan daar:

Op hierdie punt moet sy haar werk met John deel, so sy push haar featureA takvasleggings op na die bediener. Jessica het nie push-toegang tot die master tak nie — slegs die integrators het — so sy moet na 'n ander tak push om met John saam te werk:

Jessica e-pos John om hom te sê dat sy bietjie werk opgesit het in 'n tak genaamd featureA en dat hy nou daarna kan kyk. Terwyl sy wag vir terugvoer van John, besluit Jessica om aan featureB te begin werk met Josie. Om te begin, begin sy 'n nuwe kenmerktak, gebaseer op die bediener se master tak:

Nou maak Jessica 'n paar vasleggings op die featureB tak:

Jessica se bewaarplek lyk nou so:

Sy is gereed om haar werk te push, maar kry 'n e-pos van Josie dat 'n tak met 'n paar aanvanklijke “featureB” werk daaroor reeds op die bediener gepush is as die featureBee tak. Jessica moet daardie veranderings met haar eie insmelt voordat sy haar werk na die bediener kan push. Jessica haal eers Josie se veranderings af met git fetch:

Aannemende dat Jessica steeds op haar uitgecheckte featureB tak is, kan sy nou Josie se werk in daardie tak insmelt met git merge:

Op hierdie punt wil Jessica al hierdie saamgesmelte “featureB” werk terug push na die bediener, maar sy wil nie eenvoudig haar eie featureB tak push nie. Liewer, aangesien Josie reeds 'n stroomopwaartse featureBee tak begin het, wil Jessica na daardie tak push, wat sy doen met:

Dit word 'n refspec genoem. Sien Die Refspec (Verwysingspesifikasie) vir 'n meer gedetailleerde bespreking van Git refspecs en verskillende dinge wat jy daarmee kan doen. Let ook op die -u vlag; dit is kort vir --set-upstream, wat die takke opstel vir makliker push en pull later.

Skielik kry Jessica e-pos van John, wat haar vertel dat hy 'n paar veranderings na die featureA tak gepush het waarop hulle saamwerk, en hy vra Jessica om daarna te kyk. Weereens voer Jessica 'n eenvoudige git fetch uit om al die nuwe inhoud van die bediener af te haal, insluitend (natuurlik) John se jongste werk:

Jessica kan die log van John se nuwe werk vertoon deur die inhoud van die nuut afgelaaide featureA tak te vergelyk met haar plaaslike kopie van dieselfde tak:

As Jessica hou van wat sy sien, kan sy John se nuwe werk in haar plaaslike featureA tak insmelt met:

Ten slotte wil Jessica dalk 'n paar klein veranderings aan al daardie saamgesmelte inhoud maak, so sy is vry om daardie veranderings te maak, dit in haar plaaslike featureA tak vas te lê, en die eindresultaat terug te push na die bediener:

Jessica se vasleggingsgeskiedenis lyk nou so iets soos dit:

Op een of ander punt lig Jessica, Josie en John die integrators in dat die featureA en featureBee takke op die bediener gereed is vir integrasie in die hooftak. Nadat die integrators hierdie takke in die hooftak ingesmelt het, sal 'n afhaling die nuwe saamsmeltingsvaslegging (merge commit) aftrek, wat die geskiedenis so laat lyk:

Baie groepe skakel oor na Git as gevolg van hierdie vermoë om verskeie spanne in parallel te laat werk, en die verskillende werklyne laat in die proses saam te smelt. Die vermoë van kleiner subgroepe van 'n span om via afgeleë takke saam te werk sonder om noodwendig die hele span te betrek of te belemmer, is 'n enorme voordeel van Git. Die volgorde vir die werkvloei wat jy hier gesien het, is iets soos dit:

Om tot openbare projekte by te dra is 'n bietjie anders. Omdat jy nie die regte het om takke op die projek direk op te dateer nie, moet jy die werk op 'n ander manier by die instandhouers kry. Hierdie eerste voorbeeld beskryf bydraes via forking op Git-gashere wat maklike forking ondersteun. Baie gasheerwebtuistes ondersteun dit (insluitend GitHub, BitBucket, repo.or.cz, en ander), en baie projekinstandhouers verwag hierdie styl van bydrae. Die volgende afdeling handel oor projekte wat verkies om bygedragen pleisters via e-pos te aanvaar.

Eerstens wil jy waarskynlik die hoofbewaarplek kloon, 'n onderwerp-tak skep vir die pleister of pleisterreeks wat jy van plan is om by te dra, en jou werk daar doen. Die volgorde lyk basies soos dit:

Wanneer jou takwerk klaar is en jy gereed is om dit aan die instandhouers terug te gee, gaan na die oorspronklike projekblad en klik op die “Fork” knoppie, wat jou eie skryfbare fork van die projek skep. Jy moet dan hierdie bewaarplek-URL as 'n nuwe remote van jou plaaslike bewaarplek byvoeg; in hierdie voorbeeld, noem ons dit myfork:

Jy moet dan jou nuwe werk na hierdie bewaarplek push. Dit is die maklikste om die onderwerp-tak waaraan jy werk na jou gevorkte bewaarplek te push, eerder as om daardie werk in jou master tak te smelt en dit te push. Die rede hiervan is dat as jou werk nie aanvaar word nie of gekies word (cherry-picked), jy nie jou master tak hoef terug te rol nie (die Git cherry-pick operasie word meer in detail gedek in Herbasering en Cherry-Picking Werkvloeie (Rebasing and Cherry-Picking Workflows)). As die instandhouers jou werk merge, rebase, of cherry-pick, sal jy dit uiteindelik terugkry deur van hulle bewaarplek af te pull enigenaars.

In elk geval kan jy jou werk push met:

Sodra jou werk na jou fork van die bewaarplek gepush is, moet jy die instandhouers van die oorspronklike projek in kennis stel dat jy werk het wat jy wil hê hulle moet saamsmelt. Dit word dikwels 'n pull request genoem, en jy genereer tipies so 'n versoek óf via die webwerf — GitHub het sy eie “Pull Request” meganisme wat ons sal dek in GitHub — óf jy kan die git request-pull opdrag uitvoer en die daaropvolgende afvoer per e-pos aan die projekinstandhouer handmatig stuur.

Die git request-pull opdrag neem die basistak waarin jy wil hê jou onderwerp-tak moet gepulled word en die Git-bewaarplek-URL waarvan jy wil hê hulle moet pull, en produseer 'n opsomming van al die veranderings wat jy vra om gepulled te word. Byvoorbeeld, as Jessica vir John 'n pull request wil stuur, en sy het twee vasleggings gemaak op die onderwerp-tak wat sy pas gepush het, kan sy dit uitvoer:

Hierdie afvoer kan aan die instandhouer gestuur word — dit vertel hulle waar die werk van afgetak is, som die vasleggings op, en identifiseer waarvandaan die nuwe werk gepulled moet word.

Op 'n projek waarvoor jy nie die instandhouer is nie, is dit oor die algemeen makliker om 'n tak soos master altyd origin/master te laat naspeur (track) en om jou werk te doen in onderwerp-takke wat jy maklik kan weggooi as hulle geweier word. Om werktemas geïsoleer te hou in onderwerp-takke maak dit ook vir jou makliker om jou werk te rebase as die punt van die hoofbewaarplek in die tussentijd beweeg het en jou vasleggings nie meer skoon toepas nie. Byvoorbeeld, as jy 'n tweede onderwerp van werk by die projek wil indien, moenie aanhou werk aan die onderwerp-tak wat jy pas opgesit het nie — begin oor vanaf die hoofbewaarplek se master tak:

Nou is elkeen van jou onderwerpe vervat binne 'n silo — soortgelyk aan 'n pleistertou — wat jy kan herskryf, rebase en wysig sonder dat die onderwerpe inmeng of van mekaar afhanklik is, soos dit:

Sê nou die projekinstandhouer het 'n bos ander pleisters ingetrek en jou eerste tak probeer, maar dit smelt nie meer skoon saam nie. In hierdie geval kan jy probeer om daardie tak bo-op origin/master te rebase, die konflikte vir die instandhouer op te los, en dan jou veranderings opnieuw in te dien:

Dit herskryf jou geskiedenis om nou te lyk soos Vasleggingsgeskiedenis na featureA werk.

Omdat jy die tak gerebase het, moet jy die -f spesifiseer vir jou push-opdrag om die featureA tak op die bediener te kan vervang met 'n vaslegging wat nie 'n afstammeling daarvan is nie. 'n Alternatief sou wees om hierdie nuwe werk na 'n ander tak op die bediener te push (miskien featureAv2 genoem).

Kom ons kyk na nog een moontlike scenario: die instandhouer het gekyk na werk in jou tweede tak en hou van die konsep, maar wil hê jy moet 'n implementeringsdetail verander. Jy sal ook hierdie geleentheid aangryp om die werk te skuif om gebaseer te wees op die projek se huidige master tak. Jy begin 'n nuwe tak gebaseer op die huidige origin/master tak, pers (squash) die featureB veranderings daar saam, los enige konflikte op, maak die implementeringsverandering, en push dit dan as 'n nuwe tak:

Die --squash opsie neem al die werk op die saamgesmelte tak en pers dit saam in een veranderingset wat die bewaarplektoestand lewer as 'n ware saamsmelting plaasgevind het, sonder om werklik 'n saamsmeltingsvaslegging te maak. Dit beteken jou toekomstige vaslegging sal slegs een ouer hê en laat jou toe om al die veranderings van 'n ander tak in te voer en dan meer veranderings te maak voordat jy die nuwe vaslegging vaslê. Ook die --no-commit opsie kan nuttig wees om die saamsmeltingsvaslegging uit te stel in geval van die verstek saamsmeltingsproses.

Op hierdie punt kan jy die instandhouer in kennis stel dat jy die gevraagde veranderings gemaak het, en dat hulle daardie veranderings in jou featureBv2 tak kan vind.

Baie projekte het vasgestelde prosedures vir die aanvaarding van pleisters — jy sal die spesifieke reëls vir elke projek moet kontroleer, omdat hulle sal verskil. Aangesien daar verskeie ouer, groter projekte is wat pleisters via 'n ontwikkelaarmaillys aanvaar, gaan ons nou 'n voorbeeld daarvan dek.

Die werkvloei is soortgelyk aan die vorige gebruikscenario — jy skep onderwerp-takke vir elke pleisterreeks waaraan jy werk. Die verskil is hoe jy dit by die projek indien. In plaas daarvan om die projek te fork en na jou eie skryfbare weergawe te push, genereer jy e-posweergawes van elke vasleggingsreeks en e-pos dit aan die ontwikkelaarmaillys:

Nou het jy twee vasleggings wat jy na die maillys wil stuur. Jy gebruik git format-patch om die mbox-geformatteerde lêers te genereer wat jy aan die lys kan e-pos — dit verander elke vaslegging in 'n e-posboodskap met die eerste reël van die vasleggingsboodskap as die onderwerp en die res van die boodskap plus die pleister wat die vaslegging bekendstel as die liggaam. Die lekker ding hiervan is dat die toepassing van 'n pleister vanaf 'n e-pos wat met format-patch gegenereer is, al die vasleggingsinligting behoorlik behou.

Die format-patch opdrag druk die name uit van die pleisterlêers wat dit skep. Die -M skakelaar sê vir Git om te kyk vir hernoemings. Die lêers eindig op om so te lyk:

Jy kan ook hierdie pleisterlêers wysig om meer inligting vir die e-poslys by te voeg wat jy nie wil hê in die vasleggingsboodskap moet verskyn nie. As jy teks byvoeg tussen die --- reël en die begin van die pleister (die diff --git reël), kan die ontwikkelaars dit lees, maar daardie inhoud word geïgnoreer deur die pleisterproses.

Om dit aan 'n maillys te e-pos, kan jy óf die lêer in jou e-posprogram plak óf dit via 'n opdragreëlprogram stuur. Om die teks te plak veroorsaak dikwels formateringskwessies, veral met “slim” kliënte wat nie nuwelyne en ander witruimte gepas behou nie. Gelukkig bied Git 'n gereedschap om jou te help om behoorlijk geformatteerde pleisters via IMAP te stuur, wat makliker vir jou kan wees. Ons sal demonstreer hoe om 'n pleister via Gmail te stuur, wat toevallig die e-posagent is wat ons die beste ken; jy kan gedetailleerde instruksies lees vir 'n aantal posprogramme aan die einde van die bogenoemde Documentation/SubmittingPatches lêer in die Git-bronkode.

Eerstens moet jy die imap-afdeling in jou ~/.gitconfig lêer opstel. Jy kan elke waarde afsonderlik stel met 'n reeks git config opdragte, of jy kan dit handmatig byvoeg, maar uiteindelik behoort jou konfigurasielêer so iets soos dit te lyk:

As jou IMAP-bediener nie SSL gebruik nie, is die laaste twee reëls waarskynlik nie nodig nie, en die gasheerwaarde sal imap:// wees in plaas van imaps://. Wanneer dit opgestel is, kan jy git imap-send gebruik om die pleisterreeks in die Drafts-gids van die gespesifiseerde IMAP-bediener te plaas:

Op hierdie punt behoort jy in staat te wees om na jou Drafts-gids te gaan, die To-veld te verander na die maillys waarna jy die pleister stuur, moontlik die instandhouer of persoon verantwoordelik vir daardie afdeling te CC, en dit weg te stuur.

Jy kan ook die pleisters deur 'n SMTP-bediener stuur. So voorheen, kan jy elke waarde afsonderlik stel met 'n reeks git config opdragte, of jy kan dit handmatig byvoeg in die sendemail-afdeling in jou ~/.gitconfig lêer:

Nadat dit gedoen is, kan jy git send-email gebruik om jou pleisters te stuur:

Dan spoeg Git 'n bos loginligting uit wat lyk soos iets soos dit vir elke pleister wat jy stuur:

In hierdie afdeling het ons meervoudige werkvloeie gedek, en gepraat oor die verskille tussen om te werk as deel van 'n klein span op geslotebron-projekte teenoor die bydrae tot 'n groot openbare projek. Jy weet om te kyk vir witruimtefoute voordat jy vaslê, en kan 'n wonderlike vasleggingsboodskap skryf. Jy het geleer hoe om pleisters te formateer, en dit per e-pos aan 'n ontwikkelaarmaillys te stuur. Die hantering van saamsmeltings is ook gedek in die konteks van die verskillende werkvloeie. Jy is nou goed voorbereid om aan enige projek saam te werk.

Volgens sal jy sien hoe om die ander kant van die munt te werk: die instandhouding van 'n Git-projek. Jy sal leer hoe om 'n welwillende diktator of integrasiebestuurder te wees.