2.1

Fonaments de Git i per què domina el mercat

🐧
Origen: Git va ser creat el 2007 per Linus Torvalds (el creador de Linux) perquè necessitava gestionar el codi del nucli de Linux amb milers de col·laboradors.

A diferència dels sistemes antics (com SVN o CVS) que depenien d'un servidor central, Git és un sistema Distribuït (Peer-to-Peer). Cada desenvolupador té una còpia exacta i completa de tot l'historial del projecte al seu ordinador.

📶

Sense internet contínuament

Pots treballar offline. L'historial sencer és al teu ordinador.

🛡️

Còpia de seguretat distribuïda

Si el servidor central cau, qualsevol ordinador de l'equip té la còpia completa.

Extremadament ràpid

Git és molt eficient unint codis (fent merges) gràcies al seu model intern.

2.2

Conceptes Clau de Git

🗄️

Repositori

La carpeta màgica o el "magatzem" on viuen els teus arxius i tot el seu historial. Tot i ser distribuït, s'acostuma a tenir un Repositori Central (a GitHub o GitLab) com a punt de trobada per a tot l'equip.

💡 Tenir un repositori central millora la seguretat perquè evita revelar les IPs dels ordinadors personals dels treballadors.
📸

Commit

Com fer una fotografia instantània al teu codi en un moment concret. Cada fotografia rep un identificador únic (un codi hash). Sempre podràs viatjar en el temps a qualsevol commit anterior.

👆

HEAD

Un punter (com el cursor del ratolí) que li diu a Git a quina versió exacta estàs mirant o treballant actualment.

2.3

Treballant amb Branques (Branches)

Les branques són la superpotència de Git. Permeten crear una realitat paral·lela del teu codi on pots treballar de manera aïllada.

🌳 main (o master)

La branca principal on hi ha el codi bo i testejat. Si vols afegir un botó nou, crees una branca nova (ex: feature/nou-boto). Si t'equivoques, la branca main no es veu afectada.

El cicle de treball bàsic

1

Init / Clone

Creem un repositori buit o en descarreguem un d'existent del servidor.

2

Commit

Guardem els nostres canvis locals en el nostre historial personal (snapshot).

3

Fetch

Descarreguem els canvis dels companys del servidor central, però sense aplicar-los encara, només per veure'ls.

4

Merge (Fusió)

Integrem el codi dels companys amb el nostre.

!

Conflictes

Si tu i la teva companya heu modificat la mateixa línia de codi, Git demanarà intervenció humana per resoldre-ho.

⚠️
Regla d'or: Després d'un merge, cal executar TOTS els tests de nou. De vegades el teu codi funciona, el de la teva companya també, però junts provoquen un error.
2.4

Què SÍ i què NO s'ha de pujar a Git — El fitxer .gitignore

Hi ha arxius que mai s'han de pujar a un repositori, especialment si és públic en línia. Per evitar ensurts, creem un arxiu anomenat .gitignore a l'arrel del projecte.

Què hem d'ignorar i per què?

🔴 CRÍTIC

Credencials

Fitxers com els .env que contenen contrasenyes de bases de dades o claus API. És una bretxa de seguretat enorme si es pugen accidentalment.

.env secrets.json config.ini
🟠 IMPORTANT

Biblioteques de tercers

Carpetes com node_modules/ o l'entorn virtual env/. Pesen moltíssim. Millor passar un llistat de dependències i que cada ordinador les descarregui.

node_modules/ env/ venv/
🟡 RECOMANAT

Arxius temporals o memòria cau

Arxius generats pel sistema automàticament. No aporten res i embruten l'historial del repositori.

__pycache__/ *.pyc .DS_Store
🟡 RECOMANAT

Bases de dades locals

Com el fitxer db.sqlite3. Cadascú ha de tenir les seves pròpies dades de prova al seu ordinador.

db.sqlite3 *.db local.db

🗂️ Resum Ràpid — Mòdul 2

Git = Distribuït Cada dev té una còpia completa. No depèn d'un servidor central.
Repositori El magatzem del projecte. GitHub/GitLab s'usen com a punt de trobada.
Commit Fotografia del codi en un moment. Té un hash únic. Permet viatjar en el temps.
Branques Realitats paral·leles. La main conté el codi estable i testejat.
Merge → Tests! Após un merge sempre cal re-executar TOTS els tests.
.gitignore Ignora .env, node_modules, __pycache__, db.sqlite3, etc.