En contrast amb els Sistemes de Control de Versions Centralitzats (CVCS), la naturalesa distribuïda de Git us permet ser molt més flexibles en com els desenvolupadors col·laboren en projectes. En sistemes centralitzats, cada desenvolupador és un node que treballa més o menys igual amb un centre principal. En Git, però, cada desenvolupador és potencialment tant un node com un centre; és a dir, cada desenvolupador pot contribuir codi a altres repositoris i mantenir un repositori públic en el qual altres poden basar el seu treball i al qual poden contribuir. Això presenta una àmplia gamma de possibilitats de fluxos de treball per al vostre projecte i/o equip, així que tractarem alguns paradigmes comuns que aprofiten aquesta flexibilitat. Tractarem els punts forts i les possibles febleses de cada disseny; podeu triar un únic per utilitzar, o podeu combinar característiques de cadascun.
En sistemes centralitzats, generalment hi ha un únic model de col·laboració: el flux de treball centralitzat. Un únic centre principal, o repositori, pot acceptar codi, i tots sincronitzen el seu treball amb ell. Un nombre de desenvolupadors són nodes: consumidors d’aquest centre, i sincronitzen amb aquesta ubicació centralitzada.
Això significa que si dos desenvolupadors clonen des del centre i tots dos fan canvis, el primer desenvolupador que faci push dels seus canvis pot fer-ho sense problemes. El segon desenvolupador ha de fusionar el treball del primer abans de fer push dels canvis, per no sobreescriure els canvis del primer desenvolupador. Aquest concepte és tan cert en Git com ho és en Subversion (o qualsevol CVCS), i aquest model funciona perfectament bé en Git.
Si ja esteu còmodes amb un flux de treball centralitzat a la vostra empresa o equip, podeu continuar utilitzant aquest flux de treball amb Git. Simplement configureu un únic repositori i doneu a tots a l’equip accés de push; Git no permetrà que els usuaris s’escribin entre si.
Suposem que John i Jessica comencen a treballar al mateix temps. John acaba els seus canvis i els fa push al servidor. Llavors Jessica intenta fer push dels seus canvis, però el servidor els rebutja. Se li diu que està intentant fer push de canvis no de fast-forward i que no podrà fer-ho fins que faci fetch i fusioni. Aquest flux de treball és atractiu per a molta gent perquè és un paradigma amb el qual molts estan familiaritzats i còmodes.
Això també no està limitat a equips petits. Amb el model de branques de Git, és possible que centenars de desenvolupadors treballin amb èxit en un únic projecte a través de dotzenes de branques simultàniament.
Com que Git us permet tenir múltiples repositoris remots, és possible tenir un flux de treball en el qual cada desenvolupador té accés d’escriptura al seu propi repositori públic i accés de lectura al dels altres. Aquest escenari sovint inclou un repositori canònic que representa el projecte “oficial”. Per contribuir a aquest projecte, creeu el vostre propi clon públic del projecte i feu push dels vostres canvis. Llavors, podeu enviar una sol·licitud al mantenedor del projecte principal perquè incorpori els vostres canvis. El mantenedor pot llavors afegir el vostre repositori com a remot, provar els vostres canvis localment, fusionar-los a la seva branca i fer push al seu repositori. El procés funciona de la següent manera (vegeu Flux de treball de gestor d’integració):
-
El mantenedor del projecte fa push al seu repositori públic.
-
Un contribuïdor clona aquest repositori i fa canvis.
-
El contribuïdor fa push al seu propi clon públic.
-
El contribuïdor envia un correu electrònic al mantenedor demanant-li que incorpori els canvis.
-
El mantenedor afegeix el repositori del contribuïdor com a remot i fusiona localment.
-
El mantenedor fa push dels canvis fusionats al repositori principal.
Això és un flux de treball molt comú amb eines basades en centres com GitHub o GitLab, on és fàcil bifurcar un projecte i fer push dels vostres canvis a la vostra bifurcació perquè tots puguin veure’ls. Un dels principals avantatges d’aquest enfocament és que podeu continuar treballant, i el mantenedor del repositori principal pot incorporar els vostres canvis en qualsevol moment. Els contribuïdors no han d’esperar que el projecte incorpori els seus canvis: cada part pot treballar al seu propi ritme.
Això és una variant d’un flux de treball de múltiples repositoris. Generalment s’utilitza en projectes enorms amb centenars de col·laboradors; un exemple famós és el nucli de Linux. Diversos gestors d’integració són responsables de certes parts del repositori; se’ls diu tinents. Tots els tinents tenen un gestor d’integració conegut com el dictador benevolent. El dictador benevolent fa push des del seu directori a un repositori de referència del qual tots els col·laboradors han de fer pull. El procés funciona així (vegeu Flux de treball de dictador benevolent):
-
Els desenvolupadors regulars treballen a la seva branca de tema i rebasegen el seu treball sobre
master. La brancamasterés la del repositori de referència al qual el dictador fa push. -
Els tinents fusionen les branques de tema dels desenvolupadors a la seva branca
master. -
El dictador fusiona les branques
masterdels tinents a la brancamasterdel dictador. -
Finalment, el dictador fa push d’aquesta branca
masteral repositori de referència perquè els altres desenvolupadors puguin fer rebase sobre ella.
Aquest tipus de flux de treball no és comú, però pot ser útil en projectes molt grans, o en entorns molt jeràrquics. Permet al líder del projecte (el dictador) delegar gran part del treball i recollir grans subconjunts de codi en múltiples punts abans d’integrar-los.
|
Note
|
Martin Fowler ha fet una guia "Patterns for Managing Source Code Branches". Aquesta guia cobreix tots els fluxos de treball comuns de Git, i explica com/quan utilitzar-los. També hi ha una secció que compara freqüències d’integració altes i baixes. |
Aquests són alguns fluxos de treball comunament utilitzats que són possibles amb un sistema distribuït com Git, però podeu veure que moltes variacions són possibles per adaptar-se al vostre flux de treball particular del món real. Ara que podeu (esperem) determinar quina combinació de fluxos de treball us pot funcionar, tractarem alguns exemples més específics de com aconseguir els principals rols que componen els diferents fluxos. A la següent secció, aprendreu sobre alguns patrons comuns per contribuir a un projecte.