En un projecte de desenvolupament de programari que utilitza Git com a sistema de control de versions,
la gestió de les branques és important per aconseguir un flux de treball eficient i ordenat.
Les metodologies de treball amb branques s'anomenen estratègies de ramificació, que son un conjunt
de regles i pautes que defineixen com s'han de crear, fusionar i mantindre les branques en un projecte.
Aquesta part és essencial, ja que permet el desenvolupament en paral·lel de diferents funcionalitats
i garanteix la correcta integració de les diferents parts del projecte.
Existeixen diverses estratègies de ramificació però, totes, en certa manera,
comparteixen els mateixos principis bàsics:
Creació de branques de funcionalitat feature/*: Es crea una branca independent per desenvolupar cada funcionalitat.
Branca de desenvolupament develop: Estat del projecte on s'incorporen les funcionalitats acabades, però que encara no han segut publicades.
Branca principal main: Branca on es troba la versió estable del projecte.
Branca de llançament release/*: Branca on es prepara la versió final del projecte abans de publicar-la.
Branca de correcció hotfix/*: Branca per corregir errors en la versió estable del projecte.
Utilitzant aquestes característiques, es pot adaptar el flux de treball a les necessitats del projecte,
on podem decidir quin tipus de branca incorporar en la nostra metodologia de treball.
Exemple
En projectes xicotets pot ser no és necessària una branca de desenvolupament develop o branques de llançament release/*.
Les estratègies de ramificació més comuns es basen en la creació de diferents branques,
cadascuna amb un propòsit concret i una sèrie de regles per aconseguir una integració
eficient de les funcionalitats:
Branca principal (main): Branca on es troba la versió publicada i estable del projecte.
Branca de desenvolupament (develop): Branca on es troba l'estat actual del projecte, on s'incorporen les funcionalitats acabades.
Branques de funcionalitats (feature/*): Per cada nova funcionalitat es crea una branca independent,
on es codifica i es prova la nova funcionalitat.
Es creen a partir de la branca develop.
S'integren a la branca develop una vegada acabades.
Es poden eliminar després de ser integrades.
Info
Depén de l'estratègia triada, el procés d'integració es realitzarà de diferents maneres.
Branques de llançament (release/*): Branca on es preparen els canvis
per poder publicar una nova versió del projecte.
Es creen a partir de la branca develop.
Es fusionen amb les branques develop i main una vegada acabades.
Es poden eliminar una vegada fusionades.
Normalment, es crea una etiqueta amb la versió publicada.
Branques de correcció (hotfix/*): Branca per corregir errors
crítics en la versió publicada del projecte.
Es creen a partir de la branca main.
Es fusionen amb les branques develop i main una vegada acabades.
Danger
Aquestes branques sols han de ser utilitzades per corregir errors crítics
que afecten la versió publicada del projecte i han de corregir-se
immediatament.
Aquestes branques poden dificultar el flux de treball,
sobretot si es tracta de mantindrà una història lineal del projecte.
Utilitzar aquest tipus d'estratègies de ramificació presenta una sèrie d'avantatges i desavantatges
que cal tindre en compte a l'hora de decidir si val la pena utilitzar-les.
Els avantatges principals són:
Proporciona un flux de treball clar i coherent per gestionar els canvis de codi.
Permet el desenvolupament paral·lel i la prova de diferents funcions i correccions d'errors.
Ajuda a mantenir un codi estable i preparat per posat en producció.
Facilita la col·laboració entre els membres de l'equip.
Manté un ordre coherent en la història del projecte.
El principal desavantatge és:
Pot suposar una sobrecàrrega en projectes xicotets o amb pocs membres.
A més, és important adaptar la metodologia a les necessitats del projecte
i no seguir-la de forma estricta si no aporta valor afegit.
Per utilitzar les estratègies de ramificació de forma eficient,
és important seguir una sèrie de bones pràctiques que ajudaran a
mantindre l'ordre i la coherència en el projecte.
Algunes de les bones pràctiques més importants són:
Utilitzar noms de branques descriptius i coherents, que indiquen clarament el seu propòsit i contingut.
Una bona manera de fer-ho és utilitzar un prefix comú per cada tipus de branca.
Tip
Pots organitzar les branques en "directoris" utilitzant el mateix prefixe
en el nom de la branca, separat per una barra /.
feature/frontend/landing-page o feature/backend/user-authentication,
com exemple de branques de funcionalitats.
release/v1.0.0 o release/v1.1.0, com exemple de branques de llançament.
hotfix/issue-123, com exemple de branques de correcció.
Incorporeu els canvis de develop a les branques feature/* de forma regular.
És preferible mantindre les branques de funcionalitat actualitzades amb els canvis del projecte,
i d'aquesta manera, evitar resolucions de conflictes immenses en el moment d'integrar-les.
Gitflow és una de les estratègies de ramificació més conegudes
i utilitzades en projectes de desenvolupament de programari.
Aquesta metodologia es basa en la creació de les branques main, develop, feature/*, release/* i hotfix/*.
Figura 1. Esquema de branques amb Gitflow
La particularitat d'aquesta estratègia és que la fusió de les branques de funcionalitat feature/* amb la branca de desenvolupament develop
és realitza mitjançant merge --no-ff, de manera que es conserva la història de les branques de funcionalitat que es fusionen mitjançant
un commit de fusió.
gitcheckoutdevelop
gitmerge--no-fffeature/A
Figura 2. Fusió de branques mitjançant merge --no-ff
Els avantatges principals són:
Manté tot l'històric de canvis.
Permet revertir una funcionalitat fàcilment, ja que sols cal revertir un únic commit.
El principal desavantatge és:
No manté una història lineal.
En projectes amb moltes funcionalitats, la història pot ser difícil de seguir.
Aquest mètode per fusionar les branques de funcionalitat es basa en la utilització del canvi de base rebase,
per després fusionar-la de manera lineal amb merge --ff-only.
Aquesta opció combina les dues opcions anteriors per tal d'aprofitar els avantatges de cadascuna
i a la vegada minimitzar els seus desavantatges.
Aquest mètode es basa en realitzar un canvi de base rebase i després fusionar la branca de funcionalitat
mitjançant un commit de fusió amb merge --no-ff.
Aquesta opció consisteix a fusionar les branques de funcionalitat amb la branca de desenvolupament develop
mitjançant merge --squash, de manera que tots els commits de la branca de funcionalitat es fusionen
en un únic commit.
Figura 5. Fusió de branques mitjançant merge --squash
En el cas que hi hagen conflictes, una bona pràctica és integrar els canvis de develop a la branca de funcionalitat
i resoldre'ls abans de realitzar la fusió.
Per realitzar aquesta integració de canvis, es recomana utilitzar git merge --no-ff.
Figura 6. Fusió de branques mitjançant merge --no-ff + merge --squash
Com que la branca de funcionalitat serà eliminada després de la fusió,
no importa si la història de la branca de funcionalitat es manté neta o no.
Advertència
També es podria realitzar la fusió amb rebase,
però en cas de conflicte, s'hauria de resoldre en cada commit
de la branca de funcionalitat.
Els avantatges principals d'aquesta opció són:
Manté la història lineal.
Permet revertir una funcionalitat fàcilment, ja que sols cal revertir un únic commit.
Facilita la revisió de codi, ja que tots els canvis es troben en un únic commit.
Evita la sobrecàrrega de commits en la branca de desenvolupament develop.
Els desenvolupador poden despreocupar-se de com queda la història de la branca de funcionalitat,
on es poden permetre escriure micro-commits, ja que aquests desapareixeran una vegada s'hagen
integrat es canvis.
Les branques de llançament són branques temporals
que s'utilitzen per a preparar el llançament d'una versió.
Normalment, el prefix de les branques de llançament és release/.
Aquestes branques es creen a partir de la branca de desenvolupament develop
i s'utilitzen per a realitzar tasques com:
Actualitzar la versió del projecte.
Preparar paràmetres de configuració específics per a el llançament.
El flux de treball amb aquestes branques és el següent:
- Es creen a partir de la branca de desenvolupament develop.
- Es realitzen les tasques de preparació per a el llançament.
- S'integren els canvis a la branca de desenvolupament develop.
- S'integren els canvis a la branca de desenvolupament main.
Figura 7. Branques de llançament
Consell
Si el teu projecte no requereix de tasques específiques per a preparar el llançament,
pots prescindir d'aquestes branques i publicar directament des de la branca de desenvolupament develop.
Les branques de correcció són branques temporals
que s'utilitzen per a corregir errors crítics en el codi estable del projecte,
quan la seua correcció no pot esperar a la següent versió.
Perill
Aquestes branques sols han de ser utilitzades en casos d'extrema necessitat.
Normalment, el prefix de les branques de correcció és hotfix/.
El flux de treball amb aquestes branques és el següent:
Es creen a partir de la branca principal main.
Es realitzen les correccions necessàries.
S'integren els canvis a la branca de desenvolupament develop.
S'integren els canvis a la branca de desenvolupament main.
