L'Ana ja té Git instal·lat al portàtil, però abans d'escriure la seva primera ordre necessita entendre el vocabulari. Git té un lèxic propi, dens i molt precís: cada paraula —repositori, índex, HEAD, branca, remot— designa una cosa concreta, i fer servir malament un terme és la porta d'entrada a la confusió. A més, totes les ordres són en anglès mentre que la documentació en català tradueix els conceptes, així que convé manejar les dues etiquetes de cada idea des del principi.

Aquesta lliçó és un glossari raonat. No executarem operacions —això arriba al mòdul 2—, sinó que definirem què significa cada terme i com es relaciona amb els altres. L'objectiu és que quan al mòdul 3 llegeixis "fusionar la branca d'en Bruno a main", cada paraula d'aquesta frase tingui un significat nítid al teu cap.

1. Les tres zones de Git
2. Els tres estats d'un fitxer
3. Glossari essencial
4. Referències: HEAD, branques i etiquetes
5. Col·laboració: remots, clons i forks
6. Integració: fusió i rebase
7. Vocabulari català ↔ anglès
8. Com encaixen tots els termes

Tota la feina amb Git passa en tres llocs diferents. Entendre aquesta separació és el 50 % d'entendre Git.

És la carpeta que veus a l'explorador de fitxers: per a l'Ana, la carpeta gestor-tasques amb index.html, estils.css, app.js i README.md. Són fitxers normals, que pots obrir i editar amb qualsevol programa. Git no hi interfereix.

Conté una sola versió del projecte: la que estàs editant ara mateix.

És una zona intermèdia on s'acumula el que formarà la pròxima confirmació. Físicament és un fitxer binari dins de .git, anomenat index —d'aquí que aquesta zona s'anomeni indistintament staging area, index o cache, tres noms per a la mateixa cosa.

La seva raó de ser és el control. Sense ella, confirmar significaria "desa tot el que he tocat". Amb ella, l'Ana pot haver modificat cinc fitxers i decidir que només tres, o fins i tot només certes línies d'un fitxer, formen un canvi amb sentit propi. El resultat són confirmacions netes, cadascuna amb una única intenció.

És la carpeta oculta .git que hi ha dins del projecte. Conté tot l'historial: cada confirmació, cada versió de cada fitxer, totes les branques i etiquetes, la configuració local i les referències als remots.

Dues conseqüències pràctiques:

• Si copies la carpeta del projecte amb el seu .git, t'endús el projecte sencer amb el seu historial.
• Si esborres .git, l'historial desapareix i queda una carpeta corrent de fitxers. Els fitxers actuals sobreviuen; tota la resta, no.

Com a corol·lari de les tres zones, qualsevol fitxer d'un projecte Git es troba en un d'aquests estats.

Un exemple amb la carpeta de l'Ana, encara sense executar ordres:

• L'Ana crea README.md en un projecte Git acabat de crear → el fitxer està sense seguiment.
• L'Ana el prepara → passa a preparat.
• L'Ana confirma → passa a confirmat. Ara té seguiment i està net.
• L'Ana afegeix una línia al README.md → torna a estar modificat.

Un mateix fitxer pot estar en dos estats alhora: si l'Ana prepara un canvi i després torna a editar el fitxer, tindrà una part preparada i una altra modificada sense preparar. Això desconcerta al principi i té tot el sentit quan s'entén que les tres zones contenen versions independents.

Aquesta és la taula de referència de la lliçó. Consulta-la quan un terme no et soni en lliçons posteriors.

Tres mereixen un paràgraf propi, perquè són els que generen més confusió.

Confirmació (commit). No és "desar el fitxer". És registrar una instantània del projecte sencer en un moment concret, acompanyada de metadades: qui la va fer, quan, amb quin missatge i de quina confirmació anterior parteix. S'identifica per un hash com a3f5c9e2b1d4..., que a la pràctica s'abreuja als set primers caràcters (a3f5c9e). Un cop creada, és immutable.

A més, "commit" funciona com a substantiu i com a verb: fer un commit (crear una confirmació) i commitejar un canvi (registrar-lo). En català farem servir "confirmació" i "confirmar", encara que en la parla professional catalana se senti constantment l'anglicisme.

Branca (branch). Intuïtivament és "una línia de desenvolupament paral·lela". Tècnicament és molt més simple: un fitxer de text amb el hash d'una confirmació. Quan l'Ana confirma un canvi estant a la branca main, Git actualitza aquest fitxer perquè apunti a la nova confirmació. Per això crear una branca a Git és instantani: només escriu quaranta-un bytes al disc. El mòdul 3 desenvolupa això a fons.

HEAD. És la resposta a la pregunta "on soc?". Normalment HEAD apunta a una branca, i aquesta branca apunta a una confirmació. Quan canvies de branca, el que canvia és HEAD.

Existeix un cas especial anomenat HEAD desacoblat (detached HEAD): quan HEAD apunta directament a una confirmació en lloc de a una branca. Passa en posicionar-se en un punt concret de l'historial per inspeccionar-lo. No és un error, encara que el missatge que Git mostra espanti el primer cop. El tractarem al mòdul 3.

Tots tres són referències (refs): noms llegibles que apunten a confirmacions. Es diferencien pel seu comportament.

Un exemple amb gestor-tasques, escrit com a història i no com a ordres:

• L'Ana treballa a la branca main. HEAD apunta a main.
• En Bruno crea la branca formulari-validacio per afegir validació al formulari d'index.html i hi treballa. La branca d'en Bruno avança; main es queda on era.
• Quan l'aplicació es publica per primer cop, l'equip posa l'etiqueta v1.0 sobre aquella confirmació. Aquesta etiqueta ja no es mourà mai: sempre assenyalarà exactament el que es va publicar.

Per a versions publicades es recomanen les anotades, perquè deixen constància de qui va publicar què i quan. El mòdul 5 hi dedica una lliçó completa.

Aquests tres termes descriuen com un repositori es relaciona amb d'altres. El mòdul 4 els desenvolupa operativament; aquí només els definim.

Remot (remote). Un repositori diferent del teu amb el qual sincronitzes feina. No és "el servidor": és qualsevol altre repositori Git, que pot ser a GitHub, en un servidor de l'empresa o fins i tot en una altra carpeta del teu propi disc. Un repositori pot tenir diversos remots, cadascun amb un nom curt. Per convenció, el principal s'anomena origin.

Clon (clone). Còpia completa d'un repositori: tot l'historial, totes les branques, totes les etiquetes. Quan en Bruno cloni el repositori de gestor-tasques, tindrà exactament la mateixa informació que l'Ana, i Git configurarà automàticament el remot origin apuntant al lloc d'on va clonar.

Fork. Un concepte de plataforma, no de Git. És la còpia d'un repositori aliè sota el teu propi compte a GitHub, GitLab o similar, que et permet treballar-hi sense tenir permís d'escriptura a l'original. És la base del flux de contribució a projectes de codi obert, i es tracta al mòdul 7.

Els quatre verbs que es faran servir constantment a partir del mòdul 4:

La distinció entre fetch i pull és la que més problemes causa als principiants: fetch sempre és segur perquè no modifica res del que és teu; pull pot provocar fusions i conflictes.

Dues maneres d'unir la feina de dues línies de desenvolupament. Aquí només les definim; el mòdul 3 tracta la fusió i el mòdul 5, el rebase.

Fusió (merge). Integra els canvis d'una branca en una altra creant una nova confirmació —la confirmació de fusió— que té dos pares: l'última confirmació de cada branca. L'historial conserva la forma real del que va passar: dues línies que es van separar i es van tornar a ajuntar.

Rebase. Pren les confirmacions d'una branca i les reaplica una a una sobre una altra base, com si la feina s'hagués fet des del principi a partir de l'estat més recent. El resultat és un historial lineal, sense bifurcacions visibles. A canvi, les confirmacions originals se substitueixen per altres de noves amb hash diferent: és una reescriptura de l'historial.

Conflicte (conflict). Tant la fusió com el rebase poden acabar en conflicte: passa quan les mateixes línies d'un fitxer s'han canviat de manera diferent a les dues bandes, i Git no pot decidir quina és correcta. No és un error ni una fallada: és Git demanant una decisió humana. Si en Bruno i la Carla modifiquen la mateixa regla d'estils.css, hi haurà conflicte; si en Bruno toca estils.css i la Carla app.js, Git integrarà tots dos sense intervenció.

Les ordres de Git són en anglès i no es tradueixen mai. La documentació en català, en canvi, tradueix els conceptes. Aquesta taula tanca l'escletxa.

Consell lingüístic. En un equip català real sentiràs una barreja: "fes-me una pull request", "he commitejat el canvi", "cal mergejar la branca". No és incorrecte en la conversa professional. En aquest curs farem servir la terminologia en català i afegirem el terme anglès entre parèntesis el primer cop, perquè reconeguis totes dues formes.

Per tancar, un mapa mental que situa cada terme al seu lloc:

I la frase que resumeix tot el que hem vist, aplicada al nostre projecte:

Al seu repositori de gestor-tasques, l'Ana edita fitxers al seu directori de treball, prepara els canvis que vol agrupar a l'àrea de preparació i crea una confirmació que queda registrada per sempre a .git. HEAD indica en quina branca està treballant; aquesta branca avança amb cada confirmació. Quan publiquen una versió, hi posen una etiqueta. En Bruno clona el repositori des del remot origin, treballa a la seva pròpia branca i, quan acaba, la seva feina es fusiona amb la de l'Ana.

Si aquesta frase et resulta comprensible sencera, la lliçó ha complert el seu objectiu.

• Confondre "desar el fitxer" amb "confirmar". Desar a l'editor només escriu al disc; Git no s'assabenta de res fins que prepares i confirmes. Són dues operacions sense relació.
• Creure que l'àrea de preparació és una nosa. Al principi sembla un pas burocràtic de més. És justament el contrari: és el que permet que cada confirmació tingui una sola intenció en lloc de ser un calaix de sastre. En veuràs el valor tan bon punt tinguis canvis de tres tasques diferents barrejats a la teva carpeta.
• Pensar que una branca és una còpia de la carpeta. No ho és. És un punter de quaranta-un bytes. Aquesta confusió, heretada de SVN, fa que la gent eviti crear branques per por de "duplicar el projecte".
• Fer servir "fork" i "clon" com a sinònims. Clonar és endur-te una còpia al teu equip (és Git). Fer un fork és copiar el repositori al teu compte del servidor (és la plataforma). L'habitual és fer fork i després clonar el teu fork.
• Traduir "checkout" mentalment com a "confirmar". checkout significa "situar-se a", mai "desar". És un fals amic perillós perquè en alguns sistemes centralitzats significava "bloquejar un fitxer per editar-lo".
• Entendre el conflicte com una fallada. Un conflicte significa que Git ha detectat correctament que dues persones han canviat el mateix i et demana una decisió. Que aparegui és senyal que el sistema funciona.
• Consell: torna a aquesta lliçó. No cal memoritzar la taula avui. Tingues-la a mà i rellegeix-la en començar cada mòdul nou; els termes s'assenten amb l'ús.

L'Ana té el seu repositori de gestor-tasques amb index.html, estils.css, app.js i README.md confirmats. Durant una tarda de feina fa el següent, en aquest ordre:

1. Edita estils.css per canviar el color de fons.
2. Prepara estils.css.
3. Crea un fitxer nou, notes-personals.txt.
4. Edita app.js per afegir l'esborrat de tasques.
5. Torna a editar estils.css per ajustar un marge.

Indica en quin estat es troba cadascun dels cinc fitxers al final de la tarda. Compte amb el punt 5.

Tradueix aquestes cinc frases d'argot professional a un català precís fent servir la terminologia de la lliçó, i indica a quin mòdul del curs pertany cada operació:

1. "Fes-me un fork del repo i després clona-te'l."
2. "Stageja només el CSS, el JS deixa'l fora del commit."
3. "He fet pull i m'han saltat conflictes a app.js."
4. "Tagueja la versió 1.0 a la master."
5. "Rebasa la teva branca sobre main abans de mergejar."

Indica si cada afirmació és vertadera o falsa i explica per què:

1. Si esborro la carpeta .git, perdo els fitxers del meu projecte.
2. Una etiqueta es mou automàticament quan faig una nova confirmació.
3. git fetch pot provocar un conflicte de fusió.
4. Un fitxer pot estar preparat i modificat alhora.
5. Un clon conté menys informació que el repositori original.
6. HEAD sempre apunta a una branca.

Solució a l'Exercici 1

El punt interessant és estils.css: la versió que hi ha a l'àrea de preparació (amb el color nou, sense el marge) i la que hi ha al directori de treball (amb tots dos canvis) són diferents. Si l'Ana confirmés ara, l'ajust de marge no entraria a la confirmació.

Solució a l'Exercici 2

1. "Fes una còpia del repositori al teu compte (fork) i després clona-la al teu equip." → Fork: mòdul 7. Clonar: mòdul 2 i mòdul 4.
2. "Prepara només el fitxer CSS; deixa el JavaScript fora de la confirmació." → Mòdul 2.
3. "He baixat els canvis del remot i han aparegut conflictes de fusió a app.js." → Baixar: mòdul 4. Conflictes: mòdul 3.
4. "Posa una etiqueta amb el nom v1.0 sobre l'última confirmació de la branca principal." → Mòdul 5.
5. "Aplica un rebase de la teva branca sobre main abans de fusionar-la." → Rebase: mòdul 5. Fusió: mòdul 3.

Solució a l'Exercici 3

1. Fals. Els fitxers del directori de treball són fitxers normals i continuen allà. El que es perd és tot l'historial: confirmacions, branques, etiquetes i configuració local. El projecte es converteix en una carpeta corrent.
2. Fals. Aquest és el comportament d'una branca, que avança amb cada confirmació. Una etiqueta és fixa per definició: sempre assenyala la mateixa confirmació. És justament el que la fa útil per marcar versions publicades.
3. Fals. fetch només descarrega informació del remot i actualitza les referències remotes; no toca ni el teu directori de treball ni les teves branques locals, així que no pot provocar conflictes. Qui els pot provocar és pull, perquè descarrega i integra.
4. Vertader. És exactament el cas d'estils.css a l'exercici 1. Les tres zones contenen versions independents del mateix fitxer, així que hi pot haver diferències tant entre repositori i àrea de preparació com entre àrea de preparació i directori de treball.
5. Fals. Un clon conté l'historial complet: totes les confirmacions, branques i etiquetes. Aquesta és precisament la característica que defineix un sistema distribuït, com vam veure a la lliçó Què és Git?. (Existeixen clons deliberadament parcials —shallow clones— però són l'excepció, no la norma; es tracten al mòdul 10.)
6. Fals. L'habitual és que HEAD apunti a una branca, però pot apuntar directament a una confirmació: és l'estat de HEAD desacoblat (detached HEAD), que es produeix en situar-se en un punt concret de l'historial. Es tracta al mòdul 3.

Ja disposes del vocabulari que sosté la resta del curs. Els conceptes clau són tres zones (directori de treball, àrea de preparació i repositori) i tres estats (modificat, preparat, confirmat), que junts expliquen el flux bàsic de treball. Sobre ells es recolzen les referències —branques, etiquetes i HEAD—, que són noms apuntant a confirmacions, i els conceptes de col·laboració —remot, clon, fork— i d'integració —fusió, rebase, conflicte—, que desenvoluparem als mòduls 3, 4 i 5.

També has vist la correspondència català↔anglès, imprescindible perquè les ordres no es tradueixen mai i en un equip real sentiràs les dues formes barrejades.

Ja sabem com es diuen les coses. La pregunta següent és com són per dins: què desa Git exactament quan confirmes, per què els identificadors són hashos de quaranta caràcters i què hi ha dins de .git. És el contingut d'El Model de Dades de Git, la lliçó que aporta el model mental sobre el qual descansen tots els mòduls següents.