Salta el contingut

2. Instal·lació, configuració i ús de sistemes de control de versions

Els sistemes de control de versions (Version Control Systems o VCS) permeten registrar, gestionar i controlar els canvis realitzats sobre els fitxers d’un projecte al llarg del temps. Són eines fonamentals en el desenvolupament d’aplicacions web modernes, ja que faciliten el treball col·laboratiu, la traçabilitat dels canvis i la recuperació de versions anteriors del codi.

Els VCS permeten:

  • Mantindre un historial complet dels canvis.
  • Recuperar versions anteriors d’un fitxer o projecte.
  • Coordinar el treball simultani de diversos desenvolupadors.
  • Detectar conflictes entre modificacions.
  • Automatitzar processos d’integració i desplegament.
  • Garantir una major seguretat i control sobre el codi font.

Tipus de sistemes de control de versions

Sistemes centralitzats

En els sistemes centralitzats existeix un únic servidor que conté el repositori principal.

Exemples:

  • Subversion (SVN)
  • CVS

Característiques:

  • El servidor central és el punt únic de veritat.
  • Els clients descarreguen una còpia parcial del projecte.
  • Requereixen connexió al servidor per a moltes operacions.

Sistemes distribuïts

En els sistemes distribuïts cada usuari disposa d’una còpia completa del repositori i de tot l’historial.

Exemples:

  • Git
  • Mercurial

Característiques:

  • Cada còpia local és un repositori complet.
  • Moltes operacions poden realitzar-se sense connexió.
  • Major velocitat i tolerància a errors.

Actualment, Git és el sistema de control de versions més utilitzat tant en projectes professionals com en projectes de programari lliure.

Instal·lació d’un sistema de control de versions

Instal·lació de Git en Linux

En sistemes basats en Debian o Ubuntu:

sudo apt update
sudo apt install git

Comprovació de la instal·lació:

git --version

Configuració inicial

Git necessita configurar almenys el nom i el correu electrònic de l’usuari:

git config --global user.name "Vicent Jordà"
git config --global user.email "usuari@domini.com"

Consultar la configuració activa:

git config --list

Ús bàsic d’un sistema de control de versions

Les operacions més habituals en Git són:

Operació Descripció
git init Inicialitza un repositori nou
git clone Clona un repositori remot
git status Mostra l’estat dels fitxers
git add Afig fitxers a l’índex
git commit Registra els canvis
git push Envia canvis al remot
git pull Descarrega i integra canvis
git branch Gestiona branques
git merge Fusiona branques
git checkout Canvia de branca o versió

Flux de treball general en Git

El flux de treball habitual en Git es basa en diverses fases:

flowchart LR A[Directori de treball] B[Staging Area] C[Repositori local] D[Repositori remot] A -->|git add| B B -->|git commit| C C -->|git push| D D -->|git pull| C C -->|git checkout / modificació| A

Fases principals

  1. Modificació de fitxers al directori de treball.
  2. Preparació dels canvis mitjançant git add.
  3. Creació d’un commit amb git commit.
  4. Enviament dels commits al servidor remot amb git push.

2.1 Git

Definició

Git és un sistema de control de versions distribuït creat per Linus Torvalds en 2005 per al desenvolupament del nucli Linux.

Git emmagatzema instantànies (snapshots) completes dels fitxers en cada commit, permetent:

  • velocitat elevada,
  • treball distribuït,
  • branques lleugeres,
  • integració eficient de canvis,
  • alta traçabilitat.

Conceptes clau

Repositori

Un repositori és l’espai on Git emmagatzema:

  • els fitxers del projecte,
  • l’historial de canvis,
  • les branques,
  • les etiquetes,
  • la configuració del projecte.

Pot ser:

  • local → al sistema de l’usuari,
  • remot → allotjat en un servidor.

Commit

Un commit és un punt de control que registra:

  • els fitxers modificats,
  • l’autor,
  • la data,
  • un missatge descriptiu.

Exemple:

git commit -m "feat: Afig autenticació JWT"

Branch

Una branca és una línia paral·lela de desenvolupament.

Permet:

  • desenvolupar funcionalitats noves,
  • corregir errors,
  • experimentar sense afectar la branca principal.

Les branques habituals són:

  • main
  • develop
  • feature/*
  • hotfix/*

Merge

Combina els canvis d’una branca amb una altra.

git merge develop

Rebase

Reorganitza els commits sobre una altra branca per generar un historial més lineal.

git rebase main

Staging Area

La staging area o índex és una zona intermèdia entre el directori de treball i el repositori Git.

Permet seleccionar exactament quins canvis formaran part del pròxim commit.

Estats dels fitxers en Git

Git controla els fitxers segons diferents estats interns. Comprendre estos estats és fonamental per entendre el funcionament real del sistema de control de versions.

Model d’estats de Git

Un fitxer pot trobar-se en diferents situacions durant el flux de treball:

Untracked → Tracked → Modified → Staged → Committed

Fitxers untracked

Un fitxer untracked és un fitxer que Git encara no controla.

Característiques:

  • Existeix al directori del projecte.
  • No forma part del repositori.
  • Git no registrarà els seus canvis fins que siga afegit.

Exemple:

touch prova.txt
git status

Resultat:

Untracked files:
  prova.txt

Per començar a controlar-lo:

git add prova.txt

Fitxers tracked

Un fitxer **tracked_ és un fitxer que Git ja coneix i controla.

Pot trobar-se en diversos subestats:

  • sense canvis,
  • modificat,
  • preparat per al commit.

Un fitxer passa a **tracked quan:

  • s’ha afegit amb git add,
  • o ja existia en un commit anterior.

Fitxers modified

Un fitxer modified_ és un fitxer tracked** que ha sigut modificat però encara no està preparat per al commit.

Exemple:

nano app.js
git status

Resultat:

modified: app.js

En este estat:

  • Git detecta els canvis.
  • Els canvis encara no formen part del pròxim commit.

Per preparar-lo:

git add app.js

Fitxers staged

Un fitxer staged és un fitxer preparat per formar part del pròxim commit.

Els canvis s’han afegit a la staging area.

git add app.js

Ara Git considera que eixos canvis estan preparats per confirmar-se:

git commit -m "refactor: Actualitza la lògica de login"

Fitxers committed

Quan es realitza un commit, Git registra definitivament els canvis al repositori local.

git commit -m "fix: Correcció d'errors en autenticació"

En este moment:

  • Git crea una nova instantània del projecte.
  • Els fitxers tornen a estat “clean” si no hi ha noves modificacions.

Fitxers ignored

Alguns fitxers no han de formar part del repositori:

  • dependències,
  • fitxers temporals,
  • logs,
  • claus privades,
  • configuracions locals.

Per evitar que Git els controle s’utilitza el fitxer .gitignore.

Exemple de .gitignore

node_modules/
.env
*.log
dist/

Consulta de l’estat del repositori

L'ordre principal per comprovar l’estat dels fitxers és:

git status

Mostra:

  • fitxers modificats,
  • fitxers staged,
  • fitxers untracked,
  • branca actual,
  • situació respecte al repositori remot.

Cicle complet d’un fitxer en Git

Exemple pràctic

1. Crear un fitxer nou
touch index.php

Estat:

untracked
2. Afegir-lo a Git
git add index.php

Estat:

staged
3. Crear el commit
git commit -m "Afig fitxer inicial"

Estat:

committed/tracked
4. Modificar el fitxer
nano index.php

Estat:

modified
5. Tornar a preparar-lo
git add index.php

Estat:

staged

Diagrama simplificat dels estats

stateDiagram [*] --> Untracked Untracked --> Staged: git add Staged --> Committed: git commit Committed --> Modified: modificar fitxer Modified --> Staged: git add Committed --> Remote: git push

Repositoris remots

Els repositoris remots permeten compartir el projecte amb altres usuaris.

Plataformes habituals:

  • GitHub
  • GitLab
  • Bitbucket
  • Azure DevOps

Afegir un repositori remot

git remote add origin https://github.com/usuari/projecte.git

Consultar repositoris remots

git remote -v

Bones pràctiques amb Git

Commits

  • Fer commits freqüents.
  • Utilitzar missatges descriptius.
  • Evitar commits massa grans.

Exemple correcte:

feat: Implementa autenticació OAuth2

Exemple incorrecte:

canvis

Branques

  • Una funcionalitat per branca.
  • No treballar directament sobre main.
  • Integrar canvis mitjançant merge requests.

Seguretat

  • No pujar secrets ni contrasenyes.
  • Utilitzar autenticació SSH.
  • Revisar permisos dels repositoris.

Organització

  • Mantindre un .gitignore adequat.
  • Utilitzar etiquetes (tags) per marcar versions.
  • Documentar el flux de treball del projecte.

Conventional Commits

Un dels estàndards més utilitzats per escriure commits és Conventional Commits.
Aquest model permet descriure els canvis de forma clara i homogènia mitjançant un prefix que identifica el tipus de modificació realitzada.

Estructura bàsica:

tipus: descripció breu

Exemples:

feat: afegeix autenticació amb JWT
fix: corregeix error en la validació del formulari
docs: actualitza la documentació del desplegament
refactor: reorganitza l'estructura del controlador
ci: configura GitHub Actions

Prefixos habituals:

  • feat → nova funcionalitat
  • fix → correcció d'errors
  • docs → documentació
  • refactor → reorganització del codi sense canviar funcionalitat
  • test → proves
  • ci → integració contínua
  • chore → tasques de manteniment

Més informació: https://www.conventionalcommits.org/

2.2 Operacions avançades

A mesura que els projectes augmenten de grandària i complexitat, és necessari utilitzar funcionalitats més avançades de Git.

Gestió avançada de branques

Crear una branca

git branch feature-login

Canviar de branca

git checkout feature-login

Crear i canviar simultàniament

git checkout -b feature-login

Resolució de conflictes

Els conflictes apareixen quan diverses persones modifiquen les mateixes línies d’un fitxer.

Git marca automàticament les zones en conflicte:

<<<<<<< HEAD
Codi actual
=======
Codi entrant
>>>>>>> develop

Després de resoldre el conflicte:

git add fitxer
git commit

Etiquetes (tags)

Les etiquetes permeten marcar versions importants.

git tag v1.0

Etiquetes habituals:

  • versions estables,
  • desplegaments,
  • releases de producció.

Hooks

Els hooks són scripts automàtics executats abans o després de determinades operacions Git.

Exemples:

  • executar tests abans d’un commit,
  • validar format de codi,
  • impedir commits sense missatge.

2.3 Seguretat dels sistemes de control de versions

La seguretat és essencial per protegir:

  • el codi font,
  • les dades del projecte,
  • les credencials,
  • la integritat de l’historial.

Bones pràctiques de seguretat

Control d’accés

  • Assignar permisos mínims necessaris.
  • Separar permisos de lectura i escriptura.
  • Utilitzar autenticació multifactor.

Comunicacions segures

Protocols recomanats:

  • HTTPS
  • SSH

Exemple d’accés SSH:

git clone git@github.com:usuari/projecte.git

Còpies de seguretat

És recomanable:

  • replicar repositoris,
  • generar backups periòdics,
  • protegir repositoris crítics.

Protecció de branques

Les plataformes remotes permeten:

  • impedir pushes directes a main,
  • exigir revisions,
  • requerir tests automàtics.

Fitxers sensibles

Mai s’han de pujar:

  • claus API,
  • fitxers .env,
  • certificats,
  • claus SSH,
  • credencials.

Exemple

.env
id_rsa
config/secrets.yml

Eines de seguretat

Algunes eines habituals són:

Eina Funció
GitGuardian Detecció de secrets
TruffleHog Cerca de credencials
Gitleaks Escaneig de vulnerabilitats
Dependabot Detecció de dependències vulnerables

Documentació del flux de treball

És recomanable documentar:

  • estructura de branques,
  • convencions de commits,
  • procés de desplegament,
  • normes de revisió de codi,
  • estratègia de versions.

Això facilita:

  • manteniment,
  • incorporació de nous desenvolupadors,
  • escalabilitat del projecte.