El Projecte | Sobre nosaltres | Contribuir | Donacions | Llicència
HOME Els meus cursos Finalitzats
◄ Anterior
◄

Què és Git?

Següent ►
►

Abans d'escriure una sola ordre, convé entendre quin problema ve a resoldre Git i per què s'ha convertit en l'eina estàndard de la indústria del programari. Git és un sistema de control de versions distribuït: un programa que registra l'evolució d'un conjunt de fitxers al llarg del temps, permet tornar a qualsevol estat anterior i coordina la feina de diverses persones sobre el mateix codi sense que es trepitgin entre elles. En aquesta lliçó veurem com es treballava abans que existís, d'on va sortir Git, en què es diferencia dels sistemes centralitzats que el van precedir i per què va acabar imposant-se. També coneixerem l'Ana, en Bruno i la Carla, l'equip que ens acompanyarà durant tot el curs construint una aplicació anomenada gestor-tasques.

Contingut

  1. El problema: com ho fèiem abans
  2. Què és un sistema de control de versions
  3. Breu història de Git
  4. Control de versions centralitzat davant de distribuït
  5. Per què Git es va imposar
  6. Què no és Git
  7. El nostre fil conductor: gestor-tasques, l'Ana, en Bruno i la Carla

  1. El problema: com ho fèiem abans

Qualsevol que hagi treballat amb fitxers durant un temps ha inventat el seu propi sistema de control de versions. Acostuma a tenir aquest aspecte:

Escriptori/
├── gestor-tasques/
├── gestor-tasques_copia/
├── gestor-tasques_v2/
├── gestor-tasques_v2_BO/
├── gestor-tasques_v2_BO_definitiu/
├── gestor-tasques_final_v2_BO.zip
├── gestor-tasques_final_AQUEST_SI.zip
└── gestor-tasques_ana_revisat_bruno.zip

Aquest mètode funciona a mitges durant uns dies i falla estrepitosament tan bon punt el projecte creix o hi entra una segona persona. Aquests són els seus problemes concrets:

  • No se sap què va canviar. Entre _v2 i _v2_BO hi pot haver una línia de diferència o tres-centes. Per esbrinar-ho cal comparar carpeta contra carpeta a mà.
  • No se sap per què va canviar. El nom de la carpeta no explica la intenció. D'aquí a tres mesos ningú recordarà què es va arreglar a _AQUEST_SI.
  • No se sap qui ho va canviar. Si el .zip ha passat per correu entre tres persones, l'autoria es perd.
  • Ocupa moltíssim espai. Cada còpia duplica el projecte sencer encara que només hagi canviat un fitxer.
  • Fusionar és un infern. Si l'Ana toca estils.css i en Bruno toca el mateix fitxer a la seva còpia, unir les dues feines significa obrir tots dos fitxers en paral·lel i copiar línies a mà.
  • No hi ha una única veritat. Quan existeixen cinc carpetes "bones", ningú sap quina s'ha de publicar.

Un sistema de control de versions ataca exactament aquests sis punts.

  1. Què és un sistema de control de versions

Un sistema de control de versions (VCS, Version Control System) és un programa que:

  1. Desa instantànies (snapshots) de l'estat d'un projecte en moments concrets que tu decideixes.
  2. Associa a cada instantània metadades: qui la va crear, quan i amb quin missatge explicatiu.
  3. Permet recuperar qualsevol instantània anterior, comparar-ne dues o veure l'evolució d'un fitxer concret.
  4. Permet treballar en paral·lel en línies de desenvolupament independents i després unir-les.

La diferència clau amb les carpetes _BO és que l'historial deixa d'estar als noms de fitxer i passa a estar en una base de dades que el sistema gestiona per tu. Al disc només hi ha una carpeta del projecte; l'historial complet viu amagat al seu costat.

Els VCS se solen classificar en tres generacions:

Generació Exemples Idea central Limitació principal
Local RCS, SCCS Historial al mateix equip, fitxer a fitxer Un sol usuari, sense col·laboració
Centralitzada (CVCS) CVS, Subversion (SVN), Perforce Un servidor únic desa l'historial Dependència total del servidor
Distribuïda (DVCS) Git, Mercurial, Bazaar Cada còpia conté l'historial complet Corba d'aprenentatge més gran

Git pertany a la tercera generació, i aquesta decisió de disseny explica gairebé tota la resta.

  1. Breu història de Git

L'origen de Git està directament lligat al desenvolupament del kernel de Linux.

  • 1991–2002. Els pedaços del kernel s'intercanviaven per correu electrònic en forma de fitxers de text. Amb milers de col·laboradors, el sistema es va tornar inmanejable.
  • 2002. El projecte va adoptar BitKeeper, una eina distribuïda i propietària la llicència de la qual permetia el seu ús gratuït als desenvolupadors del kernel.
  • 2005. Aquella llicència gratuïta es va retirar arran d'un conflicte entre l'empresa propietària i part de la comunitat. El kernel es va quedar de cop sense sistema de control de versions.
  • Abril del 2005. Linus Torvalds va començar a escriure el seu propi sistema. Els requisits que es va marcar van ser explícits i radicals:
    • Velocitat, perquè el kernel és enorme i les operacions quotidianes havien de ser instantànies.
    • Disseny senzill al fons, encara que la interfície fos austera.
    • Suport fort per al desenvolupament no lineal, és a dir, milers de branques en paral·lel.
    • Completament distribuït, sense servidor obligatori.
    • Capacitat de gestionar projectes de la mida del kernel sense degradar-se.
    • Integritat garantida: que fos impossible corrompre l'historial sense que es notés.

El desenvolupament va ser vertiginós: en poques setmanes Git ja allotjava el seu propi codi i poc després el del kernel. El juliol del 2005 Torvalds va cedir el manteniment a Junio Hamano, que continua sent el mantenidor principal i sota la direcció del qual Git va guanyar la interfície més amable que fem servir avui.

Sobre el nom. "git" és una paraula de l'anglès britànic col·loquial que significa, aproximadament, "individu desagradable". Torvalds va bromejar dient que té el costum d'anomenar els seus projectes en honor seu. A la documentació també s'ofereixen altres lectures retroactives, com Global Information Tracker.

  1. Control de versions centralitzat davant de distribuït

Aquesta és la diferència conceptual més important de la lliçó.

El model centralitzat (CVS, Subversion)

Existeix un servidor que conté l'historial complet del projecte. Els desenvolupadors tenen al seu equip únicament una còpia de treball: els fitxers en la seva versió actual, sense historial. Per a gairebé qualsevol operació —veure l'historial, crear una branca, confirmar un canvi, comparar amb una versió antiga— cal parlar amb el servidor.

graph TD
    S[(Servidor central<br/>historial complet)]
    A["Ana<br/>còpia de treball<br/>(sense historial)"]
    B["Bruno<br/>còpia de treball<br/>(sense historial)"]
    C["Carla<br/>còpia de treball<br/>(sense historial)"]
    A -->|commit / update| S
    B -->|commit / update| S
    C -->|commit / update| S

Conseqüències directes:

  • Si el servidor està caigut o no hi ha xarxa, no es pot treballar més enllà d'editar fitxers.
  • Si el disc del servidor es perd i no hi ha còpia de seguretat, es perd tot l'historial.
  • Cada confirmació viatja per la xarxa, així que les operacions són lentes.

El model distribuït (Git)

Cada persona té un repositori complet, amb tot l'historial des de la primera confirmació. El servidor compartit existeix, però és una conveniència organitzativa, no una necessitat tècnica: és simplement un més dels repositoris, al qual tothom ha acordat sincronitzar-se.

graph TD
    R[("Repositori compartit<br/>historial complet")]
    A["Ana<br/>repositori complet<br/>+ còpia de treball"]
    B["Bruno<br/>repositori complet<br/>+ còpia de treball"]
    C["Carla<br/>repositori complet<br/>+ còpia de treball"]
    A <-->|push / fetch| R
    B <-->|push / fetch| R
    C <-->|push / fetch| R
    A <-.->|intercanvi directe possible| B

Conseqüències directes:

  • L'Ana pot consultar l'historial, confirmar canvis i crear branques en un avió sense wifi.
  • Cada clon és una còpia de seguretat del projecte sencer.
  • En Bruno i la Carla podrien intercanviar feina directament entre els seus equips sense passar pel servidor.

Taula comparativa

Aspecte Centralitzat (SVN / CVS) Distribuït (Git)
On viu l'historial Només al servidor A cada còpia del repositori
Treballar sense xarxa Pràcticament impossible Tot excepte sincronitzar
Velocitat de l'historial Depèn de la xarxa Lectura de disc local
Cost de crear una branca Alt: còpia al servidor, operació pesada Mínim: un fitxer amb un identificador
Confirmar un canvi Publica per a tothom a l'instant Local; es publica quan tu ho decideixes
Risc si cau el servidor Pèrdua de l'historial si no hi ha còpies Qualsevol clon el pot restaurar
Identificador de versió Número correlatiu (1, 2, 3…) Hash criptogràfic del contingut
Unitat de treball típica Fitxer o directori Projecte complet (instantània)
Permisos per carpeta Suportat de manera nativa No; es gestiona amb repositoris o eines externes
Fitxers binaris grans Es gestiona raonablement bé Requereix extensions com Git LFS

Cap eina és perfecta: Subversion continua sent raonable per a repositoris enormes de binaris amb permisos fins per carpeta. Però per al desenvolupament de programari, el model distribuït va guanyar de llarg.

  1. Per què Git es va imposar

Git no era l'únic sistema distribuït: Mercurial i Bazaar van aparèixer gairebé al mateix temps. Aquestes són les raons tècniques i de context que expliquen el seu domini.

5.1 Velocitat

Gairebé totes les operacions són locals. Veure l'historial d'app.js, comparar la versió actual amb la de fa un mes o canviar de branca són lectures de disc, no peticions de xarxa. En projectes on SVN trigava segons, Git triga mil·lisegons. Aquesta diferència canvia la manera de treballar: si consultar l'historial és instantani, es consulta constantment.

5.2 Branques barates

A Git, una branca és literalment un fitxer de 41 bytes que conté l'identificador d'una confirmació. Crear-la és instantani i no duplica res. Això va convertir una operació que als sistemes centralitzats era excepcional i temuda en una cosa quotidiana: una branca per cada tasca, per cada correcció, per cada experiment. Ho veurem en profunditat al mòdul 3.

5.3 Treball fora de línia

Com que cada repositori és complet, es pot confirmar, consultar l'historial, crear branques i fusionar sense connexió. La xarxa només cal per compartir la feina amb els altres, i això passa quan tu ho decideixes, no a cada canvi.

5.4 Integritat garantida

Tot a Git s'identifica per un hash criptogràfic calculat a partir del seu contingut. Si un byte d'un fitxer antic es corromp al disc, el hash deixa de coincidir i Git ho detecta. A més, cada confirmació inclou l'identificador de l'anterior, així que alterar un punt de l'historial invalida tots els posteriors. És impossible modificar el passat en silenci. El mòdul 1 hi torna amb detall a la lliçó El Model de Dades de Git.

5.5 L'àrea de preparació

Git introdueix una zona intermèdia entre "he editat fitxers" i "he registrat un canvi a l'historial", anomenada àrea de preparació o staging area. Permet construir confirmacions acurades, triant exactament quines parts de la feina entren a cadascuna. La veurem a la lliçó Terminologia Bàsica de Git.

5.6 L'efecte GitHub

A la qualitat tècnica s'hi va sumar un factor social: el naixement de GitHub el 2008, que va convertir l'intercanvi de codi en una cosa social i visible, i va popularitzar el flux de fork i pull request. Més tard van arribar GitLab, Bitbucket i altres. Avui conèixer Git és un requisit d'entrada en pràcticament qualsevol lloc tècnic.

Resum de les raons

Raó Què et permet a la pràctica
Velocitat Consultar i navegar per l'historial sense fricció
Branques barates Aïllar cada tasca, experimentar sense por
Treball fora de línia Ser productiu sense connexió, publicar després
Integritat Confiar que l'historial no s'ha alterat
Àrea de preparació Confirmacions netes i amb sentit
Ecosistema Integració amb plataformes, CI i eines

  1. Què no és Git

Aclarir els límits evita malentesos freqüents els primers dies:

  • Git no és GitHub. Git és el programa que s'instal·la al teu equip. GitHub, GitLab o Bitbucket són serveis web que allotgen repositoris Git i hi afegeixen funcionalitats pròpies (incidències, revisions, permisos). Pots fer servir Git tota la vida sense obrir un compte a cap.
  • Git no és una còpia de seguretat automàtica. Només desa el que tu li demanes que desi, quan l'hi demanes.
  • Git no és un sistema de sincronització de carpetes. No s'assembla a Dropbox: res no se sincronitza sol, i aquest és precisament l'avantatge.
  • Git no està pensat per a fitxers binaris grans. Vídeos, imatges pesades o models 3D inflen el repositori perquè no es comprimeixen bé entre versions. Per a això existeix Git LFS, que es tracta al mòdul 10.
  • Git no és un gestor de desplegaments, encara que gairebé tots els sistemes de desplegament moderns s'hi recolzen.

  1. El nostre fil conductor: gestor-tasques, l'Ana, en Bruno i la Carla

Durant els deu mòduls del curs seguirem un únic projecte. Aprendre Git amb exemples solts genera coneixement igualment solt; seguir un projecte real de principi a fi permet entendre per què es fa servir cada ordre en cada moment.

El projecte

gestor-tasques és una petita aplicació web per gestionar llistes de tasques. Comença sent una carpeta al portàtil de l'Ana amb quatre fitxers:

Fitxer Contingut
index.html Estructura de la pàgina: títol, formulari i llista de tasques
estils.css Aspecte visual
app.js Lògica: afegir, marcar i esborrar tasques
README.md Descripció del projecte i instruccions

Aquest és l'estat inicial, tal com està avui al portàtil de l'Ana. Encara no hi ha ni rastre de Git: és només una carpeta.

<!-- index.html -->
<!DOCTYPE html>
<html lang="ca">
<head>
  <meta charset="UTF-8">
  <title>Gestor de Tasques</title>
  <link rel="stylesheet" href="estils.css">
</head>
<body>
  <h1>Les meves tasques</h1>
  <form id="nova-tasca">
    <input type="text" id="text" placeholder="Què cal fer?">
    <button type="submit">Afegeix</button>
  </form>
  <ul id="llista"></ul>
  <script src="app.js"></script>
</body>
</html>

Fixa't en la senzillesa deliberada: una capçalera, un formulari amb un camp de text i un botó, i una llista buida que s'omplirà des de JavaScript. Tot l'exemple cap en una pantalla perquè l'atenció es quedi a Git i no a l'aplicació.

// app.js
const formulari = document.getElementById('nova-tasca');
const llista = document.getElementById('llista');

formulari.addEventListener('submit', function (esdeveniment) {
  esdeveniment.preventDefault();
  const text = document.getElementById('text').value;
  if (text === '') return;
  const element = document.createElement('li');
  element.textContent = text;
  llista.appendChild(element);
  formulari.reset();
});

Línia a línia: s'obtenen les referències al formulari i a la llista; s'escolta l'esdeveniment d'enviament; esdeveniment.preventDefault() impedeix que la pàgina es torni a carregar; si el camp és buit no es fa res; en cas contrari es crea un <li>, se li posa el text, s'afegeix a la llista i es buida el formulari. És intencionadament bàsic: al llarg del curs, en Bruno i la Carla l'aniran ampliant i aquests canvis seran el material dels nostres exemples.

L'equip

Persona Paper en el projecte Què aprendrem amb ella
Ana Arrenca el projecte i el manté Crear el repositori, primeres confirmacions, configuració
Bruno S'incorpora en segon lloc Clonar, treballar en branques, resoldre conflictes
Carla S'incorpora l'última Col·laboració, revisions de codi, integració contínua

El recorregut

graph LR
    M1["Mòduls 1-2<br/>L'Ana sola<br/>carpeta local"] --> M2["Mòduls 3-4<br/>Entra en Bruno<br/>branques i remot"]
    M2 --> M3["Mòduls 5-7<br/>Entra la Carla<br/>rebase, revisions, fluxos"]
    M3 --> M4["Mòduls 8-10<br/>Equip consolidat<br/>bones pràctiques, CI, escala"]

La història avança en paral·lel al temari: el que al mòdul 2 és una carpeta amb quatre fitxers, al mòdul 10 serà un repositori compartit amb branques de release, revisions de codi i integració contínua.

Errors Habituals i Consells

  • Confondre Git amb GitHub. És el malentès número u. Repeteix-t'ho mentalment: Git és el programa local; GitHub és un web que allotja repositoris Git. Tot el que farem fins al mòdul 4 funciona sense connexió a internet i sense compte en cap servei.
  • Pensar que Git desa diferències entre versions. Conceptualment, Git desa instantànies completes del projecte a cada confirmació (amb una compressió molt eficient per sota, que reutilitza el contingut que no canvia). Aquest matís, que veurem a la lliçó 01-04, explica per què canviar de branca és tan ràpid.
  • Continuar fent servir carpetes _BO "per si de cas" quan ja uses Git. És senyal de desconfiança en l'eina, i sol desaparèixer tan bon punt s'entén el model de dades. Mentrestant, no fa mal; però l'objectiu és deixar de necessitar-ho.
  • Voler memoritzar ordres abans d'entendre el model. Git té desenes d'ordres i moltes opcions. Qui memoritza receptes es bloqueja tan bon punt alguna cosa se surt del guió; qui entén el model dedueix l'ordre. Dedica temps a les lliçons 01-03 i 01-04.
  • Consell: instal·la Git encara que de moment no l'hagis de fer servir. La lliçó següent ho cobreix i així podràs experimentar tan bon punt arribem al mòdul 2.
  • Consell: tria un projecte propi com a banc de proves. A més de seguir gestor-tasques, aplicar cada lliçó a alguna cosa teva consolida l'aprenentatge molt més ràpid.

Exercicis

Exercici 1: Diagnòstic del mètode artesanal

Imagina aquesta situació real. L'Ana envia per correu a en Bruno un fitxer gestor-tasques_v2.zip. En Bruno modifica estils.css i li torna gestor-tasques_v2_bruno.zip. Mentrestant, l'Ana ha continuat treballant i ha modificat estils.css i app.js a la seva còpia.

Enumera almenys quatre problemes concrets que apareixen ara, i per a cadascun indica quina característica d'un sistema de control de versions el resoldria.

Exercici 2: Centralitzat o distribuït

Per a cadascuna d'aquestes cinc situacions, indica si és possible en un sistema centralitzat (SVN), en un de distribuït (Git), en tots dos o en cap. Justifica-ho breument:

  1. Consultar qui va modificar per últim cop la línia 12 d'app.js sense connexió a internet.
  2. Recuperar l'historial complet del projecte després que s'incendiï el servidor, si no hi ha còpies de seguretat però tres persones tenen la seva còpia de treball.
  3. Confirmar un canvi sense que la resta de l'equip el vegi encara.
  4. Restringir l'accés d'un usuari a una única subcarpeta del projecte.
  5. Crear deu branques de prova en menys d'un segon.

Exercici 3: Argumentari per a l'equip

La Carla encara treballa amb carpetes comprimides i no veu la necessitat de canviar: "jo m'organitzo bé i mai no he perdut res". Escriu un argumentari de cinc punts, un per cada benefici de Git vist a la lliçó, redactat de manera que respongui a aquesta objecció concreta (no n'hi ha prou amb llistar característiques: cal connectar-les amb la seva situació).

Solucions

Solució a l'Exercici 1

Problemes que apareixen i la seva solució:

Problema Característica que ho resol
Hi ha dues versions diferents d'estils.css i ningú sap quina és la bona Fusió assistida: el sistema combina automàticament canvis en zones diferents del fitxer i avisa només dels solapaments reals
No se sap què va canviar en Bruno exactament Comparació de versions (diff): mostra línia a línia les diferències
No se sap per què ho va canviar Missatges de confirmació: cada canvi porta una explicació escrita pel seu autor
La feina de l'Ana a app.js es pot perdre si es descomprimeix el .zip d'en Bruno a sobre Historial immutable: res no se sobreescriu; tot estat confirmat es pot recuperar
No hi ha una versió oficial del projecte Repositori compartit amb una branca principal acordada
S'han duplicat dues vegades tots els fitxers per canviar unes poques línies Emmagatzematge eficient: només es desa el contingut nou

Amb quatre d'aquests punts ben argumentats l'exercici està resolt.

Solució a l'Exercici 2

  1. Només distribuït. A Git l'historial és al disc local, així que es consulta sense xarxa. A SVN aquesta consulta requereix parlar amb el servidor.
  2. Només distribuït. Les còpies de treball de SVN no contenen historial: es recuperaria l'últim estat dels fitxers, però el passat es perdria. Qualsevol clon de Git conté l'historial íntegre i n'hi ha prou per reconstruir el servidor.
  3. Només distribuït. A SVN, confirmar (commit) publica al servidor immediatament. A Git, confirmar és local i publicar (push) és un segon pas independent.
  4. Només centralitzat (de manera nativa). SVN permet llistes de control d'accés per ruta. Git no té permisos per carpeta dins d'un repositori; es resol dividint en diversos repositoris o amb eines de la plataforma d'allotjament.
  5. Només distribuït, a la pràctica. SVN permet crear branques, però implica una operació al servidor per cadascuna. A Git cada branca és un fitxer diminut i crear-ne deu és instantani.

Solució a l'Exercici 3

Argumentari orientat a l'objecció "jo m'organitzo bé":

  1. No es tracta de tu, es tracta de l'equip. El teu ordre personal no ajuda l'Ana ni en Bruno quan tots tres toqueu app.js la mateixa tarda. Git fusiona automàticament els canvis que no se solapen i només demana intervenció humana en el conflicte real.
  2. L'historial respon preguntes que tu no pots respondre. "Per què aquesta línia és aquí?" té resposta immediata sis mesos després: qui la va escriure, quan i amb quin missatge. Cap carpeta comprimida no desa aquesta informació.
  3. Pots experimentar sense por. Amb branques barates, provar un redisseny complet d'estils.css costa un segon i descartar-lo, un altre. Sense control de versions, experimentar significa arriscar el que funciona.
  4. És la teva xarxa de seguretat, no una càrrega. No has perdut mai res encara. Un esborrat accidental, un disc avariat o un canvi mal fet a les onze de la nit són qüestió de temps; cada clon del repositori és una còpia completa del projecte.
  5. És l'idioma comú de la professió. Les revisions de codi, el desplegament automàtic i la integració contínua es recolzen en Git. Quedar-se fora no és una preferència personal: exclou del flux de treball de la resta de l'equip.

Conclusió

Git existeix perquè el mètode artesanal de les carpetes _v2_BO no escala: no explica què va canviar, ni per què, ni qui ho va fer, i fa impossible el treball en paral·lel. Va néixer el 2005 de la necessitat concreta del kernel de Linux i es va dissenyar des del primer dia per ser ràpid, distribuït, barat en branques i íntegre per construcció. El seu caràcter distribuït —cada còpia conté l'historial complet— és la decisió que el separa de sistemes centralitzats com SVN i la que explica la seva velocitat, el seu treball sense connexió i la seva resistència a fallades.

També hem conegut l'Ana, en Bruno i la Carla, i el projecte gestor-tasques que construiran al llarg del curs: avui és una carpeta amb quatre fitxers en un portàtil; al final serà un repositori compartit amb branques de release, revisions de codi i integració contínua.

El pas següent és tenir Git funcionant al teu equip. A la lliçó Instal·lant Git veurem com instal·lar-lo a Linux, macOS i Windows, com comprovar que la instal·lació és correcta i per què en aquest curs treballarem amb la línia d'ordres en lloc d'amb un client gràfic.

◄ Anterior
◄
Següent ►
►

Dominant Git: De Principiant a Avançat

Mòdul 1: Introducció a Git

Mòdul 2: Operacions Bàsiques de Git

Mòdul 3: Branques i Fusió

Mòdul 4: Treballant amb Repositoris Remots

Mòdul 5: Operacions Avançades de Git

Mòdul 6: Eines i Tècniques de Git

Mòdul 7: Estratègies de Col·laboració i Flux de Treball

Mòdul 8: Bones Pràctiques i Consells de Git

Mòdul 9: Resolució de Problemes i Depuració

Mòdul 10: Git al Món Real

El Projecte | Sobre nosaltres | Contribuir | Donacions | Llicència
© Copyright 2026. Tots els drets reservats