A la lliçó anterior vam fer servir git push diverses vegades sense explicar-lo. Tocava: calia posar el projecte al servidor per poder estudiar la recepció. Ara girem el canal i desgranem l'ordre que envia.

git push és l'ordre amb conseqüències per als altres. Tot el que has fet fins ara —confirmar, ramificar, fusionar, fins i tot equivocar-te— passava dins del teu .git/ i es podia desfer sense que ningú se n'assabentés. Un push canvia el repositori que tot l'equip fa servir com a referència. El que envies, altres ho descarreguen; i el que esborres del servidor, altres deixen de tenir-ho.

Per això aquesta lliçó dedica tant espai als rebuigs i a les opcions de forçat. Saber enviar és fàcil; saber per què el servidor et diu que no, i què és segur fer llavors, és el que distingeix algú que no destrueix la feina dels seus companys.

L'Ana envia per fi main i les seves branques al servidor de l'equip, i en Bruno i la Carla les reben.

1. Què envia exactament git push
2. El primer enviament: git push -u origin main
3. Què fa exactament el -u
4. El refspec d'enviament
5. Les formes abreujades i push.default
6. Quan el servidor diu que no: non-fast-forward
7. --force-with-lease davant de --force
8. Esborrar una branca al servidor
9. Enviar etiquetes
10. L'Ana publica les seves branques; en Bruno i la Carla les reben

La definició precisa, que és més estreta del que la gent imagina:

git push fa dues coses: puja al remot els objectes que li falten i li demana que actualitzi una referència perquè apunti a un commit concret.

Objectes i un punter. Res més.

El que NO envia:

• El teu directori de treball. Els fitxers modificats sense confirmar es queden al teu disc. Si has editat app.js i no has fet commit, aquell canvi no surt de la teva màquina per molts push que facis.
• El teu índex. L'àrea de preparació és teva i personal.
• La teva configuració. .git/config no viatja: els remots, àlies i ajustos de cada persona són seus.
• Les teves altres branques, llevat que les demanis explícitament.
• El teu reflog. El registre dels teus moviments és local.
• Els fitxers ignorats. El que no és dins d'un commit, no existeix per al push.

Aquesta primera és la més important i la font d'un desconcert clàssic: «he fet push i el meu company no veu el canvi». Gairebé sempre significa que el canvi no es va arribar a confirmar. Només viatja el que és dins d'un commit.

Aquest penúltim pas —la comprovació de fast-forward— és el cor de l'apartat 6 i la raó de gairebé tots els rebuigs.

I una conseqüència interessant: l'enviament és incremental. Git calcula quins objectes li falten al servidor i envia només aquests, comprimits en un packfile. Enviar el commit número mil d'un projecte no costa més que enviar el segon.

Tornem al moment en què l'Ana va publicar. El seu repositori tenia el remot registrat (lliçó 04-02) i l'autenticació resolta (lliçó 04-03), però mai no havia enviat res:

Val la pena llegir aquesta sortida sencera, perquè explica tot el procés:

Fixa't en l'eficiència: tota la història del projecte —quatre commits base, dues fusions, un squash, un conflicte resolt— cap en 4,87 KB. Aquesta és la compressió delta del model de dades que vam estudiar a la lliçó 01-04.

I una comprovació des del servidor:

El repositori que estava buit ja té una branca i una història.

-u és l'abreviatura de --set-upstream, i apareix absolutament a tots els tutorials de Git sense que gairebé cap expliqui què fa.

El que fa és escriure dues línies a .git/config:

Aquesta secció [branch "main"] és la branca de seguiment: l'associació entre la teva branca local main i la branca main d'origin. I a partir d'aquell moment canvien diverses coses:

La comprovació immediata:

Aquest «up to date with 'origin/main'» només apareix si hi ha seguiment configurat. Sense ell, git status no tindria amb què comparar.

El -u només cal la primera vegada que envies una branca. Després, la configuració ja està escrita i git push a seques funciona.

I recorda que a la lliçó 01-06 vam configurar això:

Amb aquest ajust (disponible des de Git 2.37), el -u és innecessari: en enviar una branca nova, Git configura el seguiment automàticament. L'Ana hauria pogut escriure simplement git push i el resultat hauria estat idèntic. L'hem fet servir explícitament perquè vegis el que passa per sota.

Tot el que fa referència a les branques de seguiment —com es consulten, com es canvien, què significa exactament aquell «2 commits ahead»— és el tema de la lliçó 04-06, la que tanca el mòdul.

A la lliçó 04-02 vam desgranar el refspec de descàrrega. El d'enviament fa servir exactament la mateixa sintaxi, i veure'l tanca el cercle.

La forma completa d'un push és:

Llegit: «envia la meva branca main i actualitza amb ella la branca main del servidor.»

Comparat amb el refspec de descàrrega, la lògica és idèntica i només s'inverteix la direcció:

En tots dos casos, esquerra = d'on surt, dreta = on va. Un cop ho veus així, deixa de ser sintaxi arbitrària.

El tercer, HEAD:main, és útil quan estàs en HEAD desacoblat o en una branca amb nom local diferent i vols enviar el que tens a main.

Aquestes dues línies són equivalents:

Git expandeix els noms curts. Però hi ha un cas en què la forma completa és obligatòria: quan la branca de destí encara no existeix i el nom és ambigu. Si al servidor hi hagués una etiqueta anomenada revisio i volguessis crear una branca amb aquest nom, Git no sabria què vols:

La solució és ser explícit:

Si deixes el costat esquerre buit, estàs enviant res a aquella referència, cosa que l'esborra:

És la sintaxi antiga d'esborrat, i la veiem a l'apartat 8.

En el dia a dia gairebé ningú escriu el refspec complet. Aquestes són les formes curtes i què significa cadascuna:

La forma 4 és la que faràs servir el 95 % de les vegades, i el seu comportament depèn d'un ajust que ja vam configurar a la lliçó 01-06:

Els valors possibles i què fan:

matching mereix un advertiment històric. Era el valor per defecte fins a Git 2.0, i provocava una sorpresa desagradable: escrivies git push pensant a enviar la branca on eres, i Git enviava de cop les vuit branques locals que tenien homònima al servidor, inclosos experiments a mitges que no volies publicar. Canviar-lo a simple va ser una de les millors decisions de Git. No el posis a matching.

I una opció que sí que és útil quan de debò vols enviar-ne diverses:

Explícit i conscient, que és com ha de ser.

Aquest és el rebuig més freqüent de Git i el que cal entendre de debò.

En Bruno es posa a treballar al matí, fa dos commits i envia:

El servidor té commits que tu no tens. Mentre en Bruno treballava, l'Ana va enviar els seus. El graf està així:

Tots dos van partir de c2a8f1e i cadascun va avançar pel seu costat. Han divergit, exactament el concepte de la lliçó 03-01.

Si Git acceptés l'enviament d'en Bruno, la referència main del servidor passaria de b4d7e93 a 3e9c2a5. I com que b4d7e93 no és un avantpassat de 3e9c2a5, els dos commits de l'Ana deixarien de ser assolibles des de cap branca: desapareixerien del projecte sense que ningú se n'assabentés, i qualsevol que clonés després no en veuria ni rastre.

Per això Git rebutja l'enviament: per no destruir feina aliena. La regla és que una referència del servidor només pot avançar de manera fast-forward, és a dir, cap a un descendent d'on era. És la mateixa noció de fast-forward del mòdul 3, aplicada ara com a mesura de protecció.

I aquí convé relacionar dues coses. Recorda de la lliçó 04-02 que el refspec de descàrrega porta un + al davant:

Aquest + permet actualitzacions no fast-forward a les teves referències remotes, perquè la seva feina és reflectir el servidor sigui quin sigui el seu estat. A l'enviament no hi ha cap + per defecte, i és deliberat: cap endins, permissiu; cap enfora, protector.

El procediment és sempre el mateix, i és exactament el que vas aprendre a la lliçó anterior:

Amb pull.ff only configurat, el pas 3 en forma de git pull s'aturarà dient Not possible to fast-forward, perquè hi ha divergència real i Git no decideix per tu. En aquest punt has d'integrar explícitament.

El que no has de fer mai és el que suggereix l'instint i algun que altre consell malintencionat d'internet:

Això sobreescriu la referència del servidor amb la teva versió, i els commits de l'Ana queden orfes. Ella els recuperarà del seu propi disc, sí, però qualsevol que cloni en aquest interval no els veurà, i el desconcert està garantit.

Aquest apartat cobreix la causa i la sortida bàsica. El tractament complet de la divergència —com decidir entre fusionar, reaplicar o replantejar; què fer si a més hi ha conflictes; com sortir dels casos embolicats— és el tema de la lliçó 09-03: Resolent Divergències amb el Remot. Aquí queda't amb tres idees:

1. El rebuig és una protecció, no una fallada.
2. La causa és sempre la mateixa: el remot té commits que tu no tens.
3. La sortida per defecte és integrar primer i enviar després.

Hi ha situacions legítimes en què necessites sobreescriure una branca del servidor: has reescrit la teva pròpia branca de treball (amb les tècniques del mòdul 5) i el resultat ja no és descendent del que hi ha publicat. En aquests casos, l'enviament normal serà rebutjat amb tota la raó, i cal forçar.

Però hi ha dues maneres de forçar, i la diferència entre elles pot ser la feina d'una tarda d'un company.

Git sobreescriu la referència del servidor sense comprovar res. Si algú havia enviat alguna cosa mentrestant, els seus commits queden orfes.

Git compara el valor actual de la referència al servidor amb el teu origin/funcionalitat/ordre-alfabetic, és a dir, amb l'última foto que tens. Si coincideixen, sobreescriu. Si no coincideixen —perquè algú ha enviat alguna cosa des del teu darrer fetch—, rebutja l'enviament:

La paraula lease és «arrendament»: tu tenies reservada la referència en un estat concret, i si ha canviat, el contracte es trenca i no s'escriu res.

La protecció es basa en la teva referència remota local. I això obre un forat:

Si fas fetch just abans, el teu origin/branca s'actualitza amb el que el company acaba d'enviar, la comparació coincideix i --force-with-lease accepta encantat… sobreescrivint precisament allò de què l'opció t'havia de protegir.

Hi ha dues maneres de fer-ho bé:

Primera: mirar abans de forçar. Un fetch seguit d'una inspecció deliberada:

Segona, i millor: dir explícitament quin valor esperes.

Aquí no depens de cap foto: li dius a Git «només escriu si el servidor és exactament a 9d1e4b7». És la forma més segura, i la que convé fer servir en scripts.

Des de Git 2.30 existeix a més una opció complementària:

Comprova, a més, que els commits que hi ha al servidor estan inclosos en el que enviaràs, és a dir, que realment els has integrat i no simplement descarregat.

1. No forcis mai main, develop ni cap branca compartida. Si l'equip hi treballa a sobre, reescriure-la obliga tothom a resoldre un embolic. I és exactament el que impedeixen les branques protegides de les plataformes.
2. Força només branques teves, de treball, que ningú més estigui fent servir.
3. Fes servir sempre --force-with-lease. Converteix --force en una paraula que no escrius.
4. Avisa l'equip si forces una branca que algú pugui tenir clonada.
5. Si dubtes, no forcis. Un historial amb un commit de fusió de més no ha matat mai ningú; un --force sobre main un divendres, gairebé.

Un àlies que ajuda que el bon costum sigui el més còmode:

I una nota tranquil·litzadora, perquè convé no viure amb por: si algú força i destrueix commits, gairebé sempre es poden recuperar. Qui els tenia al seu disc els conserva; i al servidor, el reflog o les eines de la plataforma solen permetre rescatar-los. És un embolic, no una catàstrofe. La recuperació s'estudia a la lliçó 09-04.

Quan una branca s'integra, cal esborrar-la als dos llocs: al teu repositori (amb git branch -d, lliçó 03-06) i al servidor.

Llegible i difícil de confondre. És la que has de fer servir.

Fa exactament el mateix, i ara entens per què: és el refspec <origen>:<destí> amb l'origen buit. Estàs enviant «res» a aquella referència del servidor, cosa que l'elimina.

La veuràs en documentació i en scripts antics, així que convé reconèixer-la. Però també convé saber-ne el risc: un espai de més i estàs esborrant una cosa que no volies. Compara:

Un caràcter de diferència entre publicar i destruir. Per això --delete és millor.

Esborrar una branca al servidor no esborra les referències que tenen els teus companys. Cadascun les haurà de netejar, com vam veure a la lliçó anterior:

I si a més tenen la branca local, aquesta s'esborra a part:

Tres coses diferents un altre cop: la branca del servidor, la referència remota de cadascú i la branca local de cadascú. La lliçó següent insisteix en aquesta distinció.

Un avís: esborrar una branca al servidor pot deixar els seus commits sense cap referència que els assoleixi. Si aquella branca no estava fusionada, aquests commits queden a mercè del recol·lector d'escombraries del servidor. Comprova abans amb git log --oneline main..origin/la-branca que no hi ha res a perdre.

Un detall que sorprèn gairebé tothom la primera vegada: git push no envia etiquetes.

L'etiqueta s'ha creat al teu repositori i allà es queda. El refspec per defecte només tracta branques (refs/heads/*), no etiquetes (refs/tags/*).

Les maneres d'enviar-les:

La diferència entre les dues últimes importa:

--follow-tags és gairebé sempre l'opció correcta en l'ús diari, i es pot deixar configurada:

I per esborrar una etiqueta del servidor, la mateixa sintaxi de sempre:

Què són les etiquetes, la diferència entre lleugeres i anotades, com es fan servir per marcar versions i com encaixen en el flux de publicació és el tema de la lliçó 05-05: Etiquetant Confirmacions. Aquí només ens interessa el transport: que no viatgen soles i amb quina opció s'envien.

Tanquem amb l'escenari complet de l'equip.

L'Ana té main ja publicada i dues branques locals pendents de compartir: documentacio/actualitzar-notes i correccio/focus-despres-esborrar.

Només main té branca de seguiment (els claudàtors). Les altres dues encara no existeixen al servidor.

Fixa't en l'última línia: el seguiment s'ha configurat sol, sense -u. És push.autoSetupRemote true de la lliçó 01-06 funcionant.

Ni tan sols ha calgut anomenar el remot ni la branca. Estat final:

Les branques de l'Ana són al seu disc com a referències remotes, no com a branques locals. Les pot examinar sense crear res:

La Carla fa el mateix i decideix continuar la correcció de l'Ana:

Treballa, confirma i envia:

Aquest és el cicle complet tancat. Fixa't en la forma d'aquella última línia, diferent de la del primer enviament:

• * [new branch] X -> X → s'ha creat una branca al servidor.
• 8a3f7c1..d5e9b2f X -> X → una branca existent ha avançat d'un commit a un altre, en fast-forward.

El projecte que feia tres mòduls que estava tancat en un portàtil ja circula entre tres màquines i tres sistemes operatius diferents.

Error 1: «he fet push i no veuen el meu canvi». El 90 % de les vegades, el canvi no es va arribar a confirmar. git push envia commits, no fitxers modificats. Comprova-ho amb git status i git log --oneline -3.

Error 2: respondre a un rebuig amb --force. El rebuig non-fast-forward significa que el servidor té feina que tu no tens. Forçar la destrueix. La resposta correcta és fetch + integrar + enviar. Vegeu 09-03.

Error 3: fer servir --force en comptes de --force-with-lease. El primer no comprova res; el segon s'hi nega si algú ha enviat alguna cosa des del teu darrer fetch. Costa el mateix escriure l'un que l'altre; fes un àlies.

Error 4: fer fetch just abans de --force-with-lease. Anul·la la protecció, perquè actualitza la referència amb la qual Git compara. O mires deliberadament què ha arribat, o fas servir la forma --force-with-lease=branca:hash.

Error 5: forçar una branca compartida. Reescriure main obliga tot l'equip a resoldre un embolic que no ha causat. Força només branques teves de treball.

Error 6: creure que git push envia les etiquetes. No ho fa: el refspec per defecte només cobreix refs/heads/*. Fes servir --follow-tags o configura push.followTags true.

Error 7: fer servir git push origin :branca sense fixar-s'hi. Un espai de més entre : i el nom canvia el significat del tot. Fes servir --delete, que diu el que fa.

Error 8: esborrar una branca del servidor i esperar que desaparegui del repositori dels altres. Cada persona ha de fer git fetch --prune. Configura fetch.prune true a l'equip.

Consell 1: mira abans d'enviar. git log --oneline origin/main..main t'ensenya exactament quins commits sortiran. Deu segons que eviten publicar un wip o un console.log oblidat.

Consell 2: fes git fetch abans de començar, no abans d'enviar. Així detectes la divergència quan encara és barata de resoldre, en comptes de descobrir-la amb la feina acabada.

Consell 3: àlies per al forçat segur.

Consell 4: revisa què configura push.default. El valor simple és el correcte. Si treballes en un equip amb configuracions antigues, comprova que ningú no té matching.

Consell 5: --dry-run per assajar.

Mostra què faria l'enviament sense arribar a fer-lo. Útil amb refspecs complicats o abans d'un esborrat.

Munta un servidor bare i un repositori de treball. Després:

1. Confirma tres commits i envia amb -u.
2. Mostra el .git/config abans i després, i assenyala quines línies hi ha afegit el -u.
3. Explica la sortida completa del push, línia per línia.
4. Confirma un altre commit i envia sense -u. Què canvia a la sortida i per què?
5. Comprova des del servidor que les referències són on han de ser, sense clonar.

Amb un servidor i dos clons (l'Ana i en Bruno):

1. Tots dos parteixen del mateix commit.
2. L'Ana confirma i envia.
3. En Bruno confirma (sense fer fetch) i intenta enviar.
4. Captura el missatge de rebuig i explica exactament per què s'ha produït, dibuixant el graf.
5. Resol-ho correctament sense forçar i demostra que els commits de tots dos continuen al servidor.
6. Repeteix l'experiment resolent-ho amb --force i demostra que el commit de l'Ana ha desaparegut de la branca.

Amb un repositori connectat a un bare, aconsegueix el següent i explica cada ordre:

1. Enviar la teva branca local funcionalitat/prova a una branca del servidor anomenada experimental/prova.
2. Enviar l'estat d'un commit anterior a la punta de la teva branca a una branca del servidor anomenada revisio.
3. Enviar HEAD a main estant en HEAD desacoblat.
4. Esborrar experimental/prova del servidor de les dues maneres possibles.
5. Comprovar el resultat amb git ls-remote després de cada pas.

Solució 1:

Les línies noves són la secció [branch "main"] amb remote i merge. Això és tot el que fa -u: establir la branca de seguiment.

3. La sortida, línia per línia:

• Enumerating objects: 9 — Git ha identificat 9 objectes per enviar: 3 commits + 3 arbres + 3 blobs.
• Delta compression using up to 8 threads — comprimeix en paral·lel, desant diferències entre objectes semblants.
• Writing objects: 100% (9/9), 782 bytes — la pujada real: 782 bytes.
• Total 9 (delta 1), reused 0 — dels 9 objectes, 1 s'ha desat com a diferència respecte d'un altre; cap no s'ha reutilitzat perquè el servidor estava buit.
• To /tmp/ex-push/servidor.git — el destí.
• * [new branch] main -> main — s'ha creat la branca main al servidor. L'asterisc i [new branch] marquen la creació.
• branch 'main' set up to track 'origin/main' — l'efecte del -u.

Dues diferències, i totes dues tenen explicació:

• N'hi ha hagut prou amb git push a seques: el seguiment ja estava configurat pel -u anterior, així que Git sap a quin remot i a quina branca ha d'enviar.
• La línia de resultat ja no diu [new branch] sinó 7d2f9a1..4c8e3b6: la branca ja existia i ha avançat d'un commit a un altre. Aquest rang amb dos punts indica un fast-forward, exactament la notació que vam veure al fetch.

A més, només s'han enviat 3 objectes nous en comptes dels 9 inicials: l'enviament és incremental.

Solució 2:

4. Per què: tots dos van partir de 5a1d8f3. L'Ana va crear 9e2f4a7 a sobre i el va publicar; en Bruno va crear 7d1f4b8 a sobre del mateix 5a1d8f3. El graf:

Perquè l'enviament d'en Bruno fos vàlid, 9e2f4a7 hauria de ser avantpassat de 7d1f4b8. No ho és: són branques germanes. Si el servidor acceptés l'actualització, refs/heads/main passaria a 7d1f4b8 i 9e2f4a7 deixaria de ser assolible: el commit de l'Ana desapareixeria del projecte. Git ho impedeix.

Es pot comprovar formalment:

Si el fitxer és el mateix, hi haurà conflicte (tots dos van afegir una línia al final de f.txt). Es resol amb el que vam aprendre a 03-05:

No s'ha perdut res. Les dues feines conviuen, unides per un commit de fusió amb dos pares, exactament com al mòdul 3.

Aquest + i el (forced update) són la marca del desastre:

El commit de l'Ana ja no és a la branca. Qualsevol que cloni ara no el veurà. Continua existint com a objecte solt al servidor —i evidentment al repositori de l'Ana—, però cap referència no l'assoleix. I compara-ho amb el que hauria passat fent servir l'opció segura:

Rebutjat. El servidor no era on la foto d'en Bruno deia, així que la protecció ha actuat. Aquesta és, en una línia, la raó per no escriure --force mai més.

Solució 3:

El refspec <origen>:<destí> desacobla els dos noms: a l'esquerra el que envio, a la dreta com es diu allà.

Aquí la forma completa refs/heads/revisio és necessària: com que la branca de destí encara no existeix, Git no pot deduir si vols crear una branca o una etiqueta. Amb el nom complet no hi ha ambigüitat. I fixa't que el costat esquerre és un hash, no un nom de branca: qualsevol expressió que resolgui a un commit val.

HEAD resol al commit on ets, encara que no hi hagi cap branca apuntant-lo. És la manera de publicar feina des d'un HEAD desacoblat sense haver de crear una branca local abans.

Totes dues fan el mateix. La segona és el refspec amb l'origen buit: enviar «res» a aquella referència l'elimina. És exactament la mateixa sintaxi, portada a l'extrem.

Queden main i des-de-detached; experimental/prova i revisio han desaparegut. I un detall important: les branques locals d'aquest repositori no s'han vist afectades per cap dels esborrats.

Amb aquesta lliçó, la feina de l'equip circula en els dos sentits. L'essencial:

• git push envia objectes i demana actualitzar una referència. No envia el teu directori de treball, ni el teu índex, ni la teva configuració, ni les teves altres branques. Només viatja el que és dins d'un commit.
• git push -u origin <branca>: el -u escriu la secció [branch "…"] a .git/config i estableix la branca de seguiment. A partir d'aquí, git push i git pull a seques funcionen i git status pot informar-te del desfasament. Amb push.autoSetupRemote true (lliçó 01-06) ni tan sols cal.
• El refspec d'enviament fa servir la mateixa sintaxi que el de descàrrega: origen:destí, esquerra d'on surt i dreta on va. Permet enviar a una branca amb un altre nom, enviar un commit concret o enviar HEAD.
• push.default simple envia només la branca actual. L'antic matching enviava totes les homònimes i era una font de sorpreses: no el facis servir.
• El rebuig non-fast-forward passa perquè el remot té commits que tu no tens. Si Git acceptés l'enviament, aquests commits deixarien de ser assolibles i desapareixerien del projecte. És una protecció, no una fallada. La sortida bàsica és fetch → integrar → enviar; el tractament complet, a la lliçó 09-03.
• --force-with-lease davant de --force: el primer comprova que el servidor continua on diu la teva referència remota i rebutja si algú ha enviat alguna cosa; el segon sobreescriu sense mirar i pot deixar òrfena la feina d'una altra persona. Fes servir sempre el primer, i no facis fetch just abans (o fes servir la forma --force-with-lease=branca:hash). No forcis mai branques compartides.
• Esborrar una branca del servidor: git push origin --delete <branca>, o la forma antiga git push origin :<branca> (refspec amb origen buit). Els altres hauran de fer git fetch --prune perquè desaparegui de les seves referències.
• Les etiquetes no viatgen soles: --tags les envia totes, --follow-tags només les anotades assolibles des del que envies, que sol ser el que vols. Les etiquetes, a la lliçó 05-05.

Ja saps enviar i rebre. Però al llarg d'aquestes lliçons han anat apareixent missatges que encara no hem explicat del tot: «Your branch is ahead of 'origin/main' by 2 commits», «branch 'main' set up to track 'origin/main'», aquells claudàtors de git branch -vv, i aquell git switch que crea una branca local a partir d'una de remota sense que li ho demanis.

Tot això apunta al mateix concepte: les branques de seguiment. A la lliçó 04-06: Rastrejant Branques, que tanca el mòdul, veurem què és exactament l'upstream d'una branca i on viu a .git/config, aclarirem d'una vegada la diferència entre main, origin/main i el main del servidor, i desmuntarem com calcula Git aquell «2 commits per davant». És la lliçó que lliga tots els caps del mòdul.